- 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).
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
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.
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.
* feat: improve konsole completion
* Improve konsole profile completion to be dynamic
Directly complete --profile as a long argument
* Dynamically complete konsole -p
