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.
Selectively reverts 156d4fb9b9.
`all-the-package-names` is still used to generate completions for `npm`
if it is installed, but it is not manually installed nor updated. It is
now the user's responsibility to do both, and it must be installed
globally.
`npm search` was _way_ too slow to be used for dynamic completions, so
using a cached list of all avaialable NPM packages to match against.
This is a bit brave for a fish completion, but the npm package
`all-the-package-names` has a list of, well, all the package names
avaialable for installation via the default npm registry. Installing a
copy locally to $HOME/.cache/fish/npm_completions and using that to
search for packages matching the tokenized command line.
Preference would be to call `__update_atpm` in the background, but that
emits an ugly "job has completed" message..
Should also use this for completions for `yarn add`.
This relies on the new `read --line/-L` support as an entire parser for
the output of `./configure --help` was written in fishscript. Also
doesn't work without 72f32e6d8a7905b064680ec4b578c41dea62bf84.
The completion script is slow... a function of both the autotools
configure script itself being written in a shell script combined with a
fishscript output parser.
fish's own `./configure --help` takes around 350ms to execute, while
`__fish_parse_configure ./configure` (which runs that behind the scenes)
takes around 660ms to run, all-in-all - a not insignificant overhead.
Output can be cached (based off of ./configure hash or mtime) in the
future if this is a big deal.
The default completions that autojump ships with for fish are broken
(emitting output like "1\___\#...") as they use hackes to work around
the previous lack of `complete -k`. The history-based autojump
completions fully replace it.
Now the description includes the variable scope, `set [-e] -[Ugl]`
completions only provide variables matching that scope, and completions
that shouldn't be modified are hidden from the user. Completions that
are often modified but rarely unset (`fish_*` variables) are omitted
from `set -e` completions.
A new helper function `__fish_seen_argument` has been added that makes
it easy to only provied completions for a specific flag.
* Completion for conda, the package manager
* Make the list of platforms a private variable
* Add commands activate and deactivate
* Avoid clobbering a user-defined function __
* Use Use __fish_seen_subcommand_from to identify subcommand
And treat the case of the first argument as a special case
with function __fish_conda_fist_arg
* Factor out create from loop for option --name
* Fix typo (missing parenthesis in description)
* Start from a blank state by removing completions from conda configuration script
- Cache translations instead of calling `gettext` once per file
- Only do the ":/" thing if the file isn't in $PWD/**
For a git repo created like
```fish
git init
touch a(seq 0 1000)b
```
this changes the time from about 2s to 0.3s.
`git rm --cached` is often used to delete a file that no longer exists
in the working tree but remains in git's index. `git ls-files` will list
files that are in the HEAD, which is exactly what we want. Local files
not in `HEAD` can't be deleted from git anyway.
The tool subcommand had a "-f" flag to disallow file completions which is wrong: most of the tools there require a file/directory argument.
Since we're here, also limit "go tool compile" to only match Go source files.
Now parses package.json and uses results to provide a list of possible
completions to `yarn remove`. There may be other subcommands that could
benefit from this.
Could have parsed yarn output, but yarn is slow and packages.json format
is generally standard since it's machine-generated json.
* 🚀
* prepare to merge into fish-shell
* split into different files
* remove deprecated option
* captitalize descriptions
* make shorter description for ansible
* update ansible-playbook (and ansible for consistency)
* update version on vault and galaxy
