Per the discussion with @faho in #4332, replaced some custom completion
state detection functions with standard __fish_* functions used in other
completion sources.
No longer auto-generated. Everything has been summarized. Supressing
file completions for initial command, providing list of valid initial
commands, filtering --options by subcommand.
This patch adds completion for the update subcommand, that is, when the
user types in `composer update <tab>`.
The code depends on python for the json parsing. I'm not sure if this
is appropriate or if there is a fish-native way to parse json data.
Use suggestions for remove subcommand.
Add suggestions for why, why-not and depends.
Add why/why-not suggestion.
Specifically closes#4313.
Not being as agressive in what we ignore/blacklist, but can be revisited
easily in the future to add more characters to the argument blacklist.
These completions never actually worked and always fell back to the
builtin path completion. But a recent fix means that these now keep the
fallback from happening resulting in no completions for these commands.
* Make npm run-script completion faster with `jq`
When jq is available, it's actually faster to invoke jq and parse the `package.json`
invoking the `npm` command.
Also, prior to this commit, both `__fish_complete_npm` and `__fish_npm_run` were being run
whenever completions for `npm run` subcommand was being used, which was actually making
repetitive work (invoking npm command twice). This pull request is supposed to make completion
without `jq` faster as well
* Refactor npm.fish for code reutilization
Created function to handle both cases of npm run completion parse, with or without `jq` completion.
* Remove unecessary blank line
The recent change to switch `psub` to use `argparse` caused it to use
a fifo by default because it inadvertently fixed a long standing bug in
the fish script. This changes the behavior back to `psub --file` being
the default behavior and introduces a `--fifo` flag. It also updates the
documentation to make it clearer when and why `--fifo` mode should not
be used.
Fixes#4222
While updating the `history` function to use `argparse` I realized it is
useful to define an option that can be used in three ways. First by
using the short flag; e.g., `-n NNN`. Second by using the long flag;
e.g., `--max NNN`. Third, as an implicit int flag; e.g., `-NNN`. This
use case is now supported by a spec of the form `n#max`.
A recent regression to the `alias` command points out the need for more
unit tests of its behavior. I also decided to use it as an opportunity
to normalize the output of just `alias` to list aliases.
The previous change to use `argparse` for parity with every other
builtin and function introduced a regression. Invocations that start
with a negative number can fail because the negative value looks like an
invalid flag.
