Update completions for the tree command. There are a lot of new options
were added since the 1.6.0 release (which apparently was used to create
current completions).
Options are also reordered to follow the "tree" help.
Adds a few options I see in my git manpage that were omitted:
-v, -h, -P, --config-env, --no-optional-locks, --list-cmds
Reword most general option descriptions
Simple way to make the apt completions spew:
function apt; end
on a system without an apt command installed. (even if it isn't
Darwin, because this uses test combiners!)
This is a thing some people do to avoid learning other package managers.
(of course our completions would probably be *wrong* still, but at least they
won't spew a `test` error)
The 'str' variable was apparently mistakenly removed by 49c5f96470.
Re-add it, and regex-escape it as well.
Allow completing on apropos <TAB> instaed of requiring an initial char.
Use __fish_apropos instead of apropos.
New regex to hopefully work on more platforms.
Explicitly use ^ instead of adding it at __fish_apropos
None of these __functions defined in completions are used or
referenced anywhere.
Found with:
function unused -a file search -d 'find unused functions'
set -f (string replace -fr '^[\s]*function ([\w_]+).*' '$1' < $file)
for cmd in $cmds
printf %d\ %s\n (grep -r ".*$cmd.*" $search < $argv | count) $cmd
end | string match '1 *'
end
for file in share/*/*.fish
unused $file share && printf "in %s\n" $file
end
Get rid of functions:
__fish_git_diff_opt,
__fish__git_append_letters_nosep,
__fish_git_sort_keys
Use `set -f` inside blocks instead of `set -l foo` before blocks.
Two of these just printed out the argument\tdescription dictionaries
without providing any utility: only used once, just do it inline.
Collapse adjacent lines that look like
complete git -n '(blah)' -l option -d 'option help'
complete git -n '(blah)' -l option -a 'arg1' -d 'description 1'
complete git -n '(blah)' -l option -a 'arg2' -d 'description 2'
complete git -n '(blah)' -l option -a 'arg2' -d 'description 3'
...
into
complete git -n '(blah)' -l option -d 'option help' -a "
arg1\t'description 1'
arg2\t'description 2'
arg3\t'description 3'
..."
This sped up the source time about 10% by running complete
less.
In the presence of modified files, assume `git checkout ...` is being
invoked/completed with the intention of restoring modifications. Even if not the
case, this list is likely going to be shortest if someone is about to change
branches.
Afterwards, list branches (with local branches sorted by recency), then remote
unique remotes, heads, tags, and recent commits. The order of these last four
is up for debate, and honestly if any of them generate a lot of results it makes
finding what you're actually looking for in the autocompletions a lot harder.
It may be better to merge these last contenders and sort them by individual
recency instead, but that does make the pager entries rather messy (and we would
need to add a new function to do that in order to interleave them in the desired
sort order but preserve the overall sort after the completions subshell
terminates).
It's really hard to see where -k is applied to git completions, so always group
it with -a to make it more consistent and easier to spot.
There should be no functional changes in this commit.
* Add clojure completions
* More ideomatic fish code
* Clojure completions in separate file
* Aboid use of psb using bb -e
* Return early when bb can not be found
* Remove superflous escape
* Another superflous escape
`describe-future-incompatibilities` is no longer a supported subcommand. It was
also never something very popular so we don't have to worry about older
versions.
[ci skip]
This is made much harder than it has to be by the fact that -k (where specified)
may be in any of a million different places, including as the first parameter,
as -ka, as a random standalone parameter, or tagged on to some other parameter
elsewhere; making it difficult to tell where it's actually missing!
Next job: automate cleaning up the order of arguments in this completions file.
* add adb options
only complete device serial when space after '-s' option
* keep current `adb -s` completion
* add adb reboot fastboot
* only show tcp/ip devices for disconnect
Signed-off-by: Next Alone <12210746+NextAlone@users.noreply.github.com>
* fix: files not complete when options given
Signed-off-by: Next Alone <12210746+NextAlone@users.noreply.github.com>
* fix: use old-style options for adb generic options
Signed-off-by: Next Alone <12210746+NextAlone@users.noreply.github.com>
Signed-off-by: Next Alone <12210746+NextAlone@users.noreply.github.com>
* completion/usbip: use string-match to detect remote (#9250)
* simplify output
Signed-off-by: Next Alone <12210746+NextAlone@users.noreply.github.com>
Signed-off-by: Next Alone <12210746+NextAlone@users.noreply.github.com>
I have about fifty git branches for fish and I almost always `git checkout`
between the most recent two or three - this makes the completions list more
usable. If you're using `git cherry-pick` or `git merge`, etc. you also most
likely to want to reference a recently changed branch.
The decision was made to only sort local branches and not remote ones in the PR
at #9248.
The performance of changing from one `git for-each-ref` invocation to two
separate ones (so we could sort them separately) was checked and found to be OK.
Food for future thought: consider ergonomics, caveats, and performance of
excluding the current branch's name from the list of completions (or perhaps
only from the first completion). Or maybe there's another way to have
`for-each-ref` give priority to a different branch while still sorting by
recency?
Confirmed on NetBSD: The `ls -o` option groups. I tested `ls -gon` and
it didn't give an error.
It's quite suspect that this one option couldn't be grouped, so I'm
assuming this was a typo.
`gh` doesn't write its errors to stderr and doesn't exit with a non-zero status
code in case of failure. The completions are short enough that buffering them
isn't a huge deal.
This cuts down `__fish_git_using_command` calls from 75 to 68, saving
some time in the common case.
(it would be possible to remove the check from
`__fish_git_stash_using_command` now, but that's brittle and it's one
call, so it's not a big issue)
This checked the locale, but did so in a way that's fundamentally
broken:
1. $LANG isn't the only variable ($LC_ALL and $LC_CTYPE)
2. Even if $LANG is set that doesn't mean it's actually working
We could add a `status is-multibyte` here to figure out if we have a
multibyte locale?
But instead, since this is dealing with adding an ellipsis, let's just
add it to `string ellipsize`.
One slight difference is that shortening the branch now counts the ellipsis width.
I.e. assuming the branch is "long-branch-name"
```fish
set -g __fish_git_prompt_shorten_branch_len 8
```
might now print "long-br…" instead of "long-bra…". This is nicer because we can now give the actual maximum width.
The alternative is to add a "--exclusive" option to "string ellipsize" that doesn't count the ellipsis width. So `string ellipsize --char "..." --max 8" long-branch-name` might result in "long-bra...", which is 11 wide.
This is essentially the inverse of `string pad`.
Where that adds characters to get up to the specified width,
this adds an ellipsis to a string if it goes over a specific maximum width.
The char can be given, but defaults to our ellipsis string.
("…" if the locale can handle it and "..." otherwise)
If the ellipsis string is empty, it just truncates.
For arguments given via argv, it goes line-by-line,
because otherwise length makes no sense.
If "--no-newline" is given, it adds an ellipsis instead and removes all subsequent lines.
Like pad and `length --visible`, it goes by visible width,
skipping recognized escape sequences, as those have no influence on width.
The default target width is the shortest of the given widths that is non-zero.
If the ellipsis is already wider than the target width,
we truncate instead. This is safer overall, so we don't e.g. move into a new line.
This is especially important given our default ellipsis might be width 3.
pipenv switched from older click-completion package to new built-in completions
from click framework in v2021.11.9.
This command achieves compatibility with both, older and more recent versions.
`cargo search` can be used to quickly get crates matching a search string, so we
can pass the current token for first-arg completions to `cargo add` and `cargo
install` to `cargo search` to look up matches.
`cargo search` doesn't restrict itself to (nor prioritize for) prefix matches,
while fish will only display prefix matches (for dynamically generated
completions) so it's perfectly possible for `cargo search foo` to return 20
results none of which will successfully result in a completion, but for a
further-narrowed completion of `cargo install foob^I" to then result in
completions because `cargo search` ended up returning a prefix match for `foob`
while it didn't for `foo`.
The only other oob cargo subcommand that takes a crate name (that isn't the name
of a crate specified in `Cargo.toml`) is `cargo search` but there's no point in
providing completions to that... I think (it's possible to search for crate
"foo" in order to get its latest version number rather than its name, but I'm
not sure that's worth supporting).
This expands completions of `cargo^I` to list any commands named `cargo-xxx` as
cargo subcommands invokable as `cargo xxx` in addition to the default oob
subcommands cargo ships with.
(This is very similar to how git allows users to shim their own subcommands.)
NOTE: This would stay even after cargo someday moves to clap and generates or
even ships/installs an official machine-generated `cargo.fish` completions
script.
The old way of generating cargo completions no longer work, so we need
to manually maintain the completions until clap completions support[1].
[1]: https://github.com/clap-rs/clap/issues/3166
This used `realpath -eq`, which for GNU realpath:
1. Suppresses "most error messages" (-q)
2. Requires that all parts exist (rather than allowing the last not
to)
Since we don't actually need a real path here, just filter.
Fixes#9099
* added completions for sad and added note in changelog
* ran fish_indent on completion file
* split -h and --help into two distinct completion options
A recenty commit was loathe to assume the unicode ellipsis character
was safe so just used '..' instead. However I noticed we actually
already do use that character elsehwere in the completions.
So, just make both spots try to somewhat carefully use it.
We do this same `string match` check on LANG in fish_job_summary.fish
When adding a VLAN-enabled interface, it is named like enp0s31f6.100@enp0s31f6
with the physical interface being appended behind an @.
But subsequent ip commands operate on the interface name without this suffix,
so it needs to be removed when completing interface names in __fish_ip_device
These should be friendlier, but aren't as pedantically accurate.
I think the term "index" is terrible and much prefer "staging area".
Also "rev-parse" simply must be believed to be seen, it can't be
described in a single paragraph. (did you know you can use `git
rev-parse --parseopt` as a replacement for `getopt` in arbitrary
shell scripts?)
I have an alias called "lg" for
log --color --graph --pretty=format:\'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset\' --abbrev-commit --first-parent
Having that in my completions ensures that git commands essentially
always use one column at most. That's not great, so we now shorten it
to 35 chars (plus an annoying 2 for ".." because I can't be bothered
to check for unicode support - an argument for a "string ellipsize", I guess?)
"git add ./" shows only hidden files (if at all). It should show all files
that can be added.
The problem is that candidates come from "git status" which prints clean
relative paths. Let's allow some unclean paths.
This is far from a complete fix but it should work for the common scenario.
Observe that wildcard_complete_internal() actually filters out all non-hidden
files, if the query is `./`.
Closes#9091
This can be used to print the modification time, like `stat` with some
options.
The reason is that `stat` has caused us a number of portability
headaches:
1. It's not available everywhere by default
2. The versions are quite different
For instance, with GNU stat it's `stat -c '%Y'`, with macOS it's `stat
-f %m`.
So now checking a cache file can be done just with builtins.
- Generally better descriptions,
- uname checks to not complerte unavailable options on
NetBSD, FreeBSD, DragonFly, Solaris, Darwin
- Describe/complete GNU's --time=access,mtime... arg
- Remove -f it is a no-op and not documented.
This is sort of slow because it's called hundreds of times.
We used to have a cache, introduced in ad9b4290e, but it was removed
in fee5a9125a because it had
false-positives.
So what we do, because the issue is that this is called hundreds of
times per-commandline, we cache it keyed on the commandline.
This speeds up `complete -C'git sta'` by a factor of 2.3x.
Commit ad9b4290e optimized git completions by adding a completion that would
run on every completion request, which allows to precompute data used by
other completion entries. Unfortunately, the completion entry is not run
when the commandline contains a flag like `git -C`. If we didn't
already load git.fish, we'd error. Additionally, we got false positive
completions for `git diff -c`.
So this hack was a very bad idea. We should optimize in another way.
git versions that only support porcelain v1 output (like on CentOS 7,
which has 1.8.3) weren't completing files prefixed with : correctly iff
the name after the colon was also a valid relative path.
Fixes the tests on CentOS 7.
Git's pathspec system is kind of annoying:
> A pathspec that begins with a colon : has special meaning. In the short form, the leading colon : is followed by zero or more "magic signature" letters (which optionally is terminated by another colon :), and the remainder is the pattern to match against the path. The "magic signature" consists of ASCII symbols that are neither alphanumeric, glob, regex special characters nor colon. The optional colon that terminates the "magic signature" can be omitted if the pattern begins with a character that does not belong to "magic signature" symbol set and is not a colon.
So if we complete `:/foo`, that "works" because "f" is alphanumeric
and so the "/" is the only magic character here.
If, however the filename starts with a magic character, that's used as
a magic signature.
So we do what the docs say and terminate the magic signature after the
"/" (which means "from the repo root").
Fixes#9004
`wg show` command shows entire interfaces configuration, not just the
list. This breaks completion when running fish from root, because
command output looks like this:
interface: wg0
public key: fred2rX85AxpcTObLuiWTzkRPZaXjnhd1C4XOdZOGWs=
private key: (hidden)
listening port: 12345
fwmark: 0xca6c
peer: g2YHHDkxmgoT9EV0TxKtq556WLXpaOh4zgC5L7EAGTQ=
endpoint: 192.168.88.50:54321
allowed ips: 0.0.0.0/0, ::/0
latest handshake: 1 minute, 37 seconds ago
transfer: 1.83 MiB received, 927.19 KiB sent
To show just the list of active interfaces, `wg show interfaces` should
be used instead.
Because TAGs are easy to type and complete, but commits with its SHA are
difficult to complete manualy. Keep commits and TAGs order to show more recent
commits first.
Whenever completing any git commandline, we invoke __fish_git_using_command
173 times*. Every invocation calls "commandline" and "argparse"
to the same effect. Let's parse the command line once, and reuse the results
later.
I'm observing a speed-up from 200ms to 120ms with
perf stat -r 10 buildrel/fish -c 'complete -C "git checkout ">/dev/null'
Alternative solutions:
1. teach fish to cache such things automatically.
2. rewrite git completions to compute most completions in a single function,
which will naturally avoid redundant work. This sounds viable but it's
a lot of work.
* we have a thousand uses of __fish_git_using_command, so I'm not sure why
it's only 173.
See the discussion in #8266
