I'm not sure what was up with the old completions,
`$__fish_service_commands` is not set anywhere and completions for the
command (not the service) were not being generated on my machine.
macOS and (AFAICT) most Linux distributions ship with the Info-ZIP
version of unzip, which has the `unzip -h` flag; but other
implementations of unzip do not necessarily have it (i.e. FreeBSD).
`unzip` under FreeBSD does not support `unzip -h`. Under both Linux and
FreeBSD, `unzip -v` presents the list of options, though. Using this
instead of `unzip -h` to detect the Debian-patched version of the
Info-ZIP unzip program.
These completions are apparently based on an auto-generated version,
so there's a whole bunch of rewording to be done here.
Also for some reason some of the options are mentioned more than once?
Only the first non-switch parameter to python must be a .py file, but
everything thereafter is "just another argument". This enables file
completions for 2nd+ arguments.
While this is a bit faster (mostly because it needs less processing on fish's side),
it lacks the neat description bit and the ":/" stuff doesn't work.
The boost is also not large in absolute terms (a few milliseconds).
This reverts commit 1f8e4dad9f.
This uses the same logic that git uses to determine the satus of files
and doesn't require any parsing on our end. Brings in support for
relative paths (such as `git add ../f<TAB>`). Should be faster and more
reliable than manually parsing porcelain status.
This doesn't support as many cases as the old `__git_ls_files` function
did (e.g. `renamed` is not supported, nor is `added`), both of which
_can_ be implemented on top of the new logic - but neither of which were
actually being used, anyway.
Usefulness is decreased by #4970, speed still bottlenecked by #4969.
cc @faho
This is based on what the official git completions do, and it's quite
fast.
Also only complete files after a "--" separator for `checkout`.
Fixes#4858.
This is much quicker - on the order of 100ms vs 50ms.
We shorten to 10 characters, which is statistically suitable - 3 out
of 600k commits in the linux kernel need 11 characters.
Using `git for-each-ref` both simplifies the code (no need to deal
with detached heads anymore) and speeds it up.
With 1600 branches, the time goes from ~48ms to ~16ms.
- fix capitalization
- shorten descriptions
- implement subcommand shortcuts
- add arg completion for 'limit' and 'depth' switches
- improve arg completion for list subcommand in case of -p switch
bower was calling `__fish_should_complete_args`, the old name for
`__fish_should_complete_switches.`
yarn was parsing bower.json instead of package.json.
