`xbps-query` actually parses `-Rsl` as `-Rs l`, which means that packages
without the letter "l" in their names or descriptions are not included in
`__fish_print_xbps_packages`'s output.
* Improve prompt execution time
* Change status to changes
* Remove grep/awk/sort
* Remove calls to grep/awk/sort
* Don't overwrite user defined colors
* Make look more consistent with git
This removes a weird `ls` call (that just decorates directories), and
makes it behave like normal path completion.
(really, this should be a proper option to complete)
Fixes#9285
This is an additional tool, and this function is executed on source
time so we'd spew errors.
(also remove an ineffective line - it's probably *nicer* with the
read, but that's not what's currently effectively doing anything)
I have no idea why `apt-cache --no-generate show` is so slow since it basically
dumps the contents of the cache file located at `/var/lib/dpkg/status`. We are
technically bypassing any waits on the cache lock file so this may produce
incorrect results if the cache is being regenerated in the moment, but that's a
small price to pay and the results are likely confined to simply not generating
comprehensive results.
With this change, we no longer need to truncate results to the first n matches
and we no longer only print packages beginning with the commandline argument
enabling fish's partial completions logic to offer less-perfect suggestions when
no better options are available.
Even though we are generating more usable completions, we still trounce the old
performance by leaps and bounds:
```
Benchmark #1: fish -c "complete -C\"apt install ac\""
Time (mean ± σ): 2.165 s ± 0.033 s [User: 267.0 ms, System: 1932.2 ms]
Range (min … max): 2.136 s … 2.256 s 10 runs
Benchmark #2: build/fish -c "complete -C\"apt install ac\""
Time (mean ± σ): 111.1 ms ± 1.8 ms [User: 38.9 ms, System: 72.9 ms]
Range (min … max): 108.2 ms … 114.9 ms 26 runs
Summary
'build/fish -c "complete -C\"apt install ac\""' ran
19.49 ± 0.44 times faster than 'fish -c "complete -C\"apt install ac\""'
```
Bracketed paste adds one undo entry unless the pasted text contains a '
or \. This is because the "paste" bind-mode has bindings for those keys,
so they effectively start a new undo entry.
Let's fix this by adding an explicit undo group (our first use of this
feature!).
On macOS, fish_git_prompt was failing to correctly handle the case where
another git was installed, e.g. /usr/local/bin/git from Homebrew.
Disable the workarounds in that case.
a lynx-internal hash of div.contents collided with em>a which caused
built-in styling to render much of entire pages as emphasized links.
Since switching from doxygen, we haven't had a <div class="contents">
so this workaround is no longer needed.
Our macOS workarounds involve running "xcrun" to check if Git is installed.
On a freshly upgraded Ventura system that does not have XCode or
CommandLineTools installed, "xcrun" will print this error:
xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun
on every prompt. Let's silence this error.
The `git` can already have finished here, leading to "disown: There
are no suitable jobs". This has caused a failure on Github Actions.
So we do $last_pid and silence all output, like we do in other spots
macOS ships with a stub `/usr/bin/python3` which by default opens a
dialog to install the command line tools. As we run `python3` initially
at launch, this causes the dialog to appear on first run of fish, if the
command line tools are not installed.
Fix this by detecting the case of `/usr/bin/python3` on Darwin without
the command line tools installed, and do not offer that as a viable
python.
git on macOS has two hazards:
1. It comes "preinstalled" as a stub which pops a dialog to install
command line developer tools.
2. It may populate the xcrun cache when run for the first time, which
may take several seconds.
We fix these as follows, both fixes limited to Darwin:
1. If git is `/usr/bin/git` and `xcode-select --print-path` fails,
then do not run git automatically.
2. Second, if there is no file at `xcrun --show-cache-path`, we take it
as an indication that the cache is not yet populated. In this case we
run `git` in the background to populate the cache.
Credit to @floam for the idea.
Fixes#9343. Fixes#6625.
I often hit Shift-Return accidentally, which makes my terminal echo a
weird escape sequence. Traditionally, terminals interpret Shift-Return
as Return, so let's follow that behavior. Analoguous to commit 1dc526884
(Bind Shift+Space CSI u sequence to Space, 2022-04-24).
Prior to this change, abbreviations were stored as fish variables, often
universal. However we intend to add additional features to abbreviations
which would be very awkward to shoe-horn into variables.
Re-implement abbreviations using a builtin, managing them internally.
Existing abbreviations stored in universal variables are still imported,
for compatibility. However new abbreviations will need to be added to a
function. A follow-up commit will add it.
Now that abbr is a built-in, remove the abbr function; but leave the
abbr.fish file so that stale files from past installs do not override
the abbr builtin.
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.
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
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.
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.
