Under FreeBSD, as annoying as it is, switches must directly follow the
command or subcommand in question, and cannot come after actual payload
argument. Calling `zpool get all -H` instead of `zpool get -H all`
caused error messages to be spewed to the console under FreeBSD when
simply completing `zfs <TAB>`, this should fix that. The change should
also be compatible with other operating systems (namely Linux) that
don't have this requirement, as they (generally) allow arguments to come
before _or_ after the primary non-switch argument (though I do not have
access to a zfs-enabled Linux machine to test this).
Previously, trying to complete a token with any of these
expansion-related characters would cause the completion to return no
results, as it would emit expanded values which weren't matched by the
autocompleter.
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.
Akin to __fish_complete_suffix, __fish_complete_directories now attempts
to complete the current commandline token if no token is explicitly
passed in as an argument.
The prompt is a fallback that is overridden via a function file
anyway.
Do that with the title as well, so we can use just builtins.
This removes error messages when $fish_function_path is borked.
Turns out that `make -pn` actually takes a while - about 300ms on
fish's makefile.
That's quite a bit of time just to throw away the output and use the
exit code.
So we just check for "GNU" in the version string.
It would be nice to just _do_ the completion and fall back on the
BSD-style if it doesn't work, but that is tricky to do with the pipe
to `awk` - the awk expression actually does not fail if `make` does
not print output.
And I don't know enough about awk to change that.
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.
For usage in completion scripts.
Unlike `__fish_is_first_token` (which is probably not correctly named),
`__fish_is_first_arg` returns true regardless of whether existing tokens start with `-`
or not, to be used when an arg cannot be used with any other argument.
`__fish_prev_arg_in` is similar to `__fish_seen_...` but it explicitly
tests the preceding token only, for arguments that take only a single
parameter.
As it turns out, for some terminals backspace is \b but only when
preceded by \e.
All this makes about as much sense as the english language.
Fixes#4955.
The previous completion generation was broken for several reasons:
* ./foo would break detection of suffix due to the leading . being
interpreted an extension marker,
* ./foo would be completed as foo, which would be excluded from
matching inrcomplete.cpp
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.
To be used by completions to directly determine whether it is either
possible or preferable to complete a switch (instead of a subcommand),
(presuming that switches must come before subcommands).
* __fish_can_complete_switches: we are in a position where a switch may
be placed.
* __fish_should_complete_switches: we're in a position to accept a
switch and the current token starts with `-` so we have no choice but
to do so.
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`.
Instead, attempt to extract the message that _would_ be displayed on
execution of `./configure --help` by relying on some markers present in
autoconf-generated configure files.
As measured with 'hyperfine' on a laptop running in reduced frequency
power savings mode, `fish -c "__fish_parse_configure ./configure"`
runtime dropped from ~1.25s to ~0.8ms, which is inline with the
previously observed ~350ms execution time for `./configure --help`.
fish's own startup time is approximately 75ms before parsing begins.
Still very slow, but much better.
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.
The job expansion wrapper was swallowing `-n` (and presumably `-e` and
others) when that was the literal argument we needed to emit. Using
`printf %s ...` instead.
