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
This moves the stuff that creates skeleton/boilerplate files to
the same place we initialize uvars for the first time or on upgrade.
Being a bit less aggresssive here theoretically makes launch a little
lighter but really I personally just found it weird I couldn't
just delete my empty config.fish file without it getting recreated
and sourced every launch.
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?)
"socket.has_ipv6" is basically useless - it tells you python has
been *compiled* with ipv6 support.
Instead just try ipv6 and if that fails with EAFNOSUPPORT (checking
the actual errno), try v4.
Yes, I explicitly do not care to test this on python2.
Fixes#3857
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 reimplements ridiculousfish/control_r which is a more future-proof
approach than #6686.
Pressing Control+R shows history in our pager and allows to search filter
commands with the pager search field.
On the surface, this works just like in other shells; though there are
some differences.
- Our pager shows multiple results at a time.
- Other shells allow to use up arrow/down arrow to select adjacent entries
in history. Shouldn't be hard to implement but the hidden state might
confuse users and it doesn't play well with up-or-search, so this is
left out.
Users might expect the history pager to use subsequence matching (fuzzy
matching) like the completion pager, however due to the history pager design it
uses substring matching. We could change this in future, however that means
we would also want to change the ordering from "reverse-chronological" to
"longest common subsequence" (e.g. what fuzzy finders do), because otherwise
a query "fis" might give this ordering:
fsck /dev/disk/by-partlabel/Linux\x20filesystem
fish
which is probably not what the user wants.
The pager shows only a small number of history items at a time. This is
because, as explained above, the history pager does not support subsequence
matching, so navigating it does not scale well.
Closes#602
These are used in prompts only, and it feels weird not to have them.
In practice, fish_color_host_remote would not be used at all (just
because you switched from the default theme!), while fish_color_status
would fall back on a different value.
That'll be adjusted in the next commit.
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.
/etc/hosts specifies, that everything after a #-character is to be
treated as a comment. The current __fish_print_hostnames however only
considers #-characters at the beginning of a line.
Thus the comment from following valid hosts-entry would end up in the
completion output:
1.2.3.4 myhost # examplecomment
getent hosts properly handles comments.
- 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.
When we want to print something while the prompt is still active, we move the
cursor by printing a newline for each line in the prompt beyond the first
one. As established by 80fe0a7fc (fish_job_summary: Format message better
for multiline prompts, 2022-06-28), our use of "string repeat" actually
prints an extra newline. Let's remove it here as well.
This was supposed to be number of lines in the prompt minus 1, but
string repeat added one.
Also it triggered even in case of the stopped job message, which is
already repainted differently.
So we add it when we need to repaint ourselves.
As a bonus add a newline before in that case so the message isn't
awkwardly printed into the commandline.
Fixes#9044.
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.
Discussions with the tmux maintainer show that:
1. We no longer need the passthrough sequence at all (and it's
deactivated by default)
2. Tmux can check if the outer terminal supports cursor shaping
Fixes#8981
This commit lets you check the manpage for a leading command by moving
the cursor over it, matching the behavior of tab complete.
It also lets you select the man page for the base of a two-part command
like `string match`.
The additional regex case is added because
`commandline -t` returns an empty string when the cursor is after a
space, e.g. at the end of 'sudo ', which the later checks don't handle.
This diagram shows the manpage picked for different cursor positions:
> sudo -Es time git commit -m foo
+-------++---++--++------------+
| || || || |
| || || |+------------+
| || || | git-commit
| || |+--+
| || | git
| |+---+
| | time
+-------+
sudo
* updated function __fish_print_portage_repository_paths.fish to support file, dir and modified defaults
* Revised version of share/functions/__fish_print_portage_repository_paths.fish
* improved syntax and regex as suggested
The recent improvements to multiline prompts and vi-mode in #3481 appear
to be sufficient to make iTerm2 well behaved, so remove our hack which
disabled it by default.
Fixes#3696
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.
