flatpak completions gate some features behind checks like
test $flatpakversion -gt 1.2
which does a floating point comparison, which is different
from version comparison.
Most of these version checks are irrelevant anyway because they check for
a version that's not even in Debian oldstable. The only one that might be
relevant is a check for version 1.5 but that only gates some extra subcommands;
there's little harm in providing them too.
So let's just remove the version check.
Hopefully fixes#9341 (untested)
Note that flatpak upstream provides a completion file too - but it's shadowed
by ours on my system. This is a tricky issue for another day.
Previously an environment variable to redefine would only be suggested if you
had not yet started typing one out. This makes it so that `env C<TAB>` will also
complete to, for example, [ `CC=`, `CXXFLAGS=`, ... ].
It also is smarter when suggesting variable names to complete: if a variable has
already been completed, it isn't suggested again. Additionally, it only suggests
names for variables that are exported, not all variables (the previous list was
insanely long and including things like all our `fish_...` variables).
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.
Introduced with 3.6.0 `fish_cursor_selection_mode` variable breaks
existing vi bindings (for example, input sequence `abc<Esc>0vd` doesn't
delete the `a` character as would be expected).
This patch fixes it by switching `fish_cursor_selection_mode` to
`inclusive` and back.
When this was introduced, we used fish_indent --ansi to format
the output of `builtin functions` for color output in `type`, etc.
We don't anymore.
Today it's not a potential showstopper if one launches a fish
session with a five year-old fish_indent in $PATH. We need not
go to lengths to try to make sure we run whatever is in the
build dir adjacent to the `fish` binary.
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.
For security reasons, some terminals require explicit permission from the
user to interpret OSC 52. One of them is [tmux] but that one usually runs
inside another terminal. This means we can usually write directly to the
underlying terminal, bypassing tmux and the need for user configuration.
This only works if the underlying terminal is writable to the fish user,
which may not be the case if we switched user. For this reason, keep writing
to stdout as well, which should work fine if tmux is configured correctly.
[tmux]: https://github.com/tmux/tmux/wiki/Clipboard
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.
