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
