When running inside SSH, Control-X runs a clipboard utility on the remote
system. For pbcopy (and probably clip.exe too) this means that we write to the
remote system's clipboard. This is usually not what the user wants (although
it is consistent with fish_clipboard_paste). When X11 forwarding is used,
xclip/xsel copy to the SSH client's clipboard, which is what most users want.
When we don't have X11 forwarding, we need a different solution. Fortunately,
modern terminal emulators implement the OSC 52 escape sequence for setting
the clipboard of the terminal's system. Use it in fish_clipboard_copy.
Tested in SSH and Docker containers on foot, iTerm2, kitty, tmux and xterm
(this one requires "XTerm.vt100.allowWindowOps: true").
Should also work in GNU screen and Windows Terminal. On terminals that don't
support OSC 52 (like Gnome Terminal or Konsole), it seems to do nothing.
Since there does not seem to be a way to feature-probe OSC 52, let's just
always do both (pbcopy and friends as well as OSC 52). In future, we should
probably stop calling pbpaste and clip.exe, at least on remote systems.
I think there is also an escape sequence to request pasting the system
clipboard but that's less important and less popular, possibly due to
security concerns.
This makes the output a little easier on the eyes.
Tests appear to not need any changes to pass. I always forget whether or not
littlecheck cares about whitespace.
Two different bugs completely broke `trap -p`. First bug broke filtering of
functions with trap handlers (`functions -na` prints functions separated by a
comma, not a new line). Second bug broke showing of function definitions for
traps because a refactor renamed only some call sites but references to `$i`
renamed.
These issues were introduced in a6820cbe and appear to have been caught just in
time: no released version is affected (changes made post-3.5.1).
It's a variable that holds all potential directories. The old name
makes it confusing to look at some of its usage sites and figure out
what is actually going on because they make no sense if $dir is only one
entry.
Don't just save known color values but any values that could have been loaded
from a .theme file.
Also, refactor the theme variable name whitelist/filter in a shared "global"
variable so we never forget to update it at any of the individual use sites.
The documentation states that running `fish_config theme save` after
`fish_config theme choose [theme_name]` will result in "saving" the
currently chosen theme, but this does not match the actual behavior of
`fish_config theme save` which expects a trailing argument specifying
the name of the theme to select/persist.
Given that the documented way has been included in a release and that it
makes more sense than calling `fish_config theme save xxx` when you are
*loading from* xxx and not *saving to* xxx, this patch revises
`fish_config.fish` to support the documented behavior.
When `fish_config theme save xxx` is used, xxx is loaded w/ its specified colors
saved to the according variables in the universal scope. But if `fish_config
theme save` is used without a theme's name specified, then the currently
specified (known) fish color variables are persisted from whatever scope they're
currently in (usually in the global scope from previewing a theme) to universal
variables of the same name.
This does *not* catch color variables unknown to fish! If a theme and a
prompt agree on some variable to hold some color but it's not a color variable
known to fish, it won't be persisted!
Closes#9088.
This makes these tools usable in a pipe.
You can run
```fish
some-long-command | fish_clipboard_copy
```
to copy some command's output to your clipboard, and
```fish
fish_clipboard_paste | some-other-command
```
To feed your clipboard to some command.
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]
We only erase existing globals for some of the theme-related variables
but not for all the `known_colors`, causing `fish_config` to still emit
warnings for these if saving a theme choice after trying it.
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?
There are a million existing ways of skinning this cat, but it's a good parallel
to `__fish_seen_argument` to have, in a similar vein to
`__fish_seen_subcommand_from`.
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.
Commit 09685c3682 tried making the apt
completions faster by doing two things:
1. Introduce a limiting "head"
2. Re-replace our "string" usage with tr
Unfortunately, in doing so it introduced a few issues:
1. The "tr" had a dangling "+" so it cut apart package
descriptions that contained a "+".
This caused e.g. "a C++ library" to generate another completion
candidate, "library".
2. In reusing "tr" it probably reintroduced #8575,
as tr is not 8-bit-clean.
3. It filtered too early, on the raw apt-cache output,
which caused it to fill up with long descriptions.
So e.g. for "texlive" it would only generate 10 completions,
where it should have matched 54 packages.
Because most of the speedup is in the "head" stopping early, we
instead go back to the old string way, but introduce a limiting "head"
after the "sed" (which will have removed everything but the package
name line and the first line of the description)
In my tests this is about ~10% slower than doing head early and using
tr, but it's more correct.
Admittedly I haven't been able to reproduce the 35s scenario that
09685 talks about, but the most likely cause of that is *apt-cache*
being slow - I don't see how string can be that much slower on another
system - and so it will most likely also be fixed by doing head here.
Future possibilities here include:
1. Using "apt-cache search --names-only", which gives a much nicer
format (but only for non-installed packages - the search strings are
apparently ANDed?)
2. Switching to `string split`, possibly using NUL and using `string
split0`?
3. Introducing a `string --null-in` switch so we can get by with one
`string`
4. (multi-threaded execution so the `string`s run in parallel)
`apt-cache` is just so incredibly slow that filtering against the final results
just doesn't cut it. Attempting to match against 'ac.*' (already taking
advantage of changing short search terms into prefix-only matches) would take
35 seconds, all of bottlenecked before the filtering step. This change uses more
of a heuristic to filter `apt-cache` results directly (before additional
filtering) to speed things up.
A variety of different limits from 100 to 5000 were timed and their result sets
compared to see what ended up artificially limiting valid completions vs what
took too long to be considered functional/usable and this is where we ended up.
`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)
* Replace ";" with "\n" in alias-generated functions
This can let us add a "#" in our aliases to make
them ignore additional arguments.
* Update changelog about aliases that ignore arguments
* Update test for alias.fish
This is now compliant with the aliases that can
ignore arguments.
This used a prompt command, but since the prompt was interpolated and
included a `?` it would be run as a glob without qmark-noglob.
Since it's simpler to pass a prompt string, just do that.
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.
