This was overly smart and tried to not show you e.g. global variables
unless you were setting without scope or explicitly global.
That is annoying when you do
`set -g fish_col<TAB>`
and don't get colors because they're universal, but you could
overwrite them.
We *could* elide e.g. local variables if we're setting a global, but I
can see someone wanting to set a universal variable on basis of a
global ("save this"), so I would rather not try to find the very
specific cases where this works.
1. Leave the indentation
2. Leave the "NAME" header - without the first line would be
unindented
3. Leave the "SYNOPSIS" header
We use $MANPAGER here, so it should be formatted like a manpage.
The alternative is to write special docs for this use-case, which
would be shorter and point towards the full man page.
Fixes#10625
They are already presented in normal mode, and I presume were forgotten to be
added in visual mode
I don't add it to ./CHANGELOG.rst because it's a minor change that can be
considered as a bug fix
When `manpath` prints a symlink to a directory, `/usr/libexec/makewhatis`
ignores the entire directory:
```
$ /usr/libexec/makewhatis -o /tmp/whatis \
(/usr/bin/manpath | string split :)
makewhatis: /Users/wiggles/.nix-profile/share/man: Not a directory
```
This means that the built-in `man` completions will not index any commands in
these directories.
If we pass the directories to `readlink -f` first, `makewhatis` correctly
indexes the `man` pages.
```
$ /usr/libexec/makewhatis -o /tmp/whatis \
(/usr/bin/manpath | string split : | xargs readlink -f)
```
We keep having to extend these with new terminals, and I can no longer
find a terminal that fails this.
Even emacs' ansi-term can now at least reliably ignore the sequence.
- the __fish_seen_any_argument function did not work
- the xxd_exclusive_args specification was not correct
- longer old-style options were missing
- technically short options are also old-style options in xxd
- some options were missing
- -q silenced warnings in apk 2.x but not in in 3.x, so redirect stderr
to /dev/null to avoid seeing warnings while completing (-q is still
passed to `apk search` as it strips package versions and releases)
- Drop `-q` from `apk info`, as on apk 3.x it prevents apk info from
outputting anything at all
I've tested these changes on both Chimera Linux (which uses apk 3.x)
and Alpine Linux (which is still using 2.x).
This except clause was too narrow, so it would fail here even on other
systems just because webbrowser.get() returned nothing usable
Now it will fail *later* with "could not locate runnable browser", but
at least it won't say anything about chromeos on non-chromeos systems.
The \e\e\[A style is bad but iTerm and putty (alt-left) use it.
The main motivation for this change is to improve fish_key_reader output.
Part of #10663
Both are plenty fast enough, but this way the output of fish_trace isn't
completely taken over by the loops (seems fair since fish_trace probably gets
used rather heavily for completions).
Preliminary work. Might be important to check version if options I added aren't widely available.
Changed some short options to old-style options since they can't be grouped and don't even need spaces before their arguments, such as `less -ooutputfile` which creates `outputfile`.
The -Dxcolor argument is commented out because its arguments follow complex rules I didn't look into in depth
Part of #1842
The implementation is obviously isn't 100% vi compatible, but works good enough
for major cases
This commit depends on previous commits where jump-{to, till}-matching-bracket
motions were introduces
This was vexing me for a while because the extraneous output presented as a
valid (but unwanted) completion, i.e. with RUSTC_WRAPPER exported, `env RUSTC_W`
would offer `RUSTC_W=` and `RUSTC_WRAPPER=` as completions (when only the latter
should have been offered up).
This blames to a40b019, when @floam made some changes to various completions,
but this one seems to not quite fit the pattern and had a copy/paste error
resulting in using an undeclared variable.
Also disable filename completion on port.
__kld_whatis is an order of magnitude faster than calling `whatis` by means of
`__fish_whatis`. (It could be even faster if we could somehow tell `string
replace` to return after the first result, since the .Nd line comes at the start
of the file.)
It still takes some ~3.5 to print descriptions for all available klds (864 under
FreeBSD 13), so we still need to decide when it's prudent to do so and when it's
not.
* completions/magento: Fixes module aggregation for module related commmands
Previousely when attempting completion for commands `module:enable`,
`mmodule:disable` and `module:uninstall` and error would be disaplyed,
stating that "magento" was not found.
Upon inspection of the issue in the related completion script it became
clear that:
1. The shell command `magento` does not exist as the CLI script of
Magentoresides under `bin/magento`.
2. The module aggregation would not work after referncing the
appropriate CLI command as an undeclared variable was being
introspected.
3. Using Magento's CLI command took too long to respond as it has to
bootstrap the whole Magento stack in order to deliver modules.
Thus the whole aggregation was rewritten to a form that actually works
and reduces the aggregation to reading the appropriate information
directly from the configuration file, provided that the file exists and
PHP is installed.
* completions/magento: Refactors module aggregation for module related commmands to not use PHP script
Executing random scripts from fish completion poses a threat to the
system. While this would indicate that the Magento installation has been
corrupted, it still is better to not run `app/etc/config.php` to get
hold of the modules.
Thus the module aggregation was rewritten to make use of `sed` instead,
which has the additional benefit of being faster than using PHP.
One issue with fish_add_path at the moment is that it is sometimes a bit too intransparent.
You'll try to add a path, but it won't appear - was that because it wasn't a directory,
or because it doesn't exist, or because it was already included?
If it isn't usable after, did fish_add_path not add it because of something or did something *else* remove it?
So we give more explanations - "skipping this because it's a file", "not setting anything because no paths are left to add", ...
fish_add_path can be used either interactively, in the commandline,
or in config.fish. That's its greatest strength, it's a very
DWIM-style command.
One of the compromises that entails, however, is that it can't really
be very loud about what it does. If it skips a path, it can't write a
warning because it might be used in config.fish.
But it *can* if it's used interactively. So we try to detect that case
and enable verbose mode automatically.
That means if you do
```fish
fish_add_path /opt/mytool/bin/mytool
```
it may tell you "Skipping path because it is a file instead of a
directory:".
The check isn't perfect, it goes through status current-command and
isatty, but it should be good for most cases (and be false in config.fish).
The value completions were rendered almost entirely useless due to the forced
inclusion of file completions at all tokens, including in the head/command
position thanks to the use of `__fish_complete_subcommand` which doesn't
understand the semantics of `env` and expects something like `ssh`. But we don't
need it at all.
Don't fork/exec an external process, especially one performing IO, if we don't
have to.
This, in turn, speeds up __fish_source_cached_completions which is rather slow
under WSL (and slower than it needs to be on other platforms).
* feat: improve konsole completion
* Improve konsole profile completion to be dynamic
Directly complete --profile as a long argument
* Dynamically complete konsole -p
* Properly handle a lot more -Z completion formats as suggested by `rustc -Z
help`
* Don't run any `rustc` commands when sourcing `rustc.fish`; these invocations
are instead deferred until the user attempts to complete the specific switch.
* Support CSV -A/F/D/W values
We don't set this variable ourselves, but some might set it in their config out
of habit coming from shells that don't automatically colorize ls output.
This variable overrides stdout tty detection for `ls --color=auto` (but does not
modify the behavior of `ls --color=never` or `ls --color=always` regardless of
its value) under at least the BSD version of `ls`. (Under the GNU version, it
influences colorization only if stdout *is* a tty.)
If we detect CLICOLOR_FORCE *and* we are not writing directly to the tty, we
skip colorization (by clearing-but-not-erasing `$__fish_ls_color_opt`, so that
we don't end up accidentally using its value from another scope).
