This prevents leaking the escape sequence by printing nonsense, and it
also allows disabling cursor setting by just setting the variable to
e.g. empty.
And if we ever added any shapes, it would allow them to be used on new
fish and ignored on old
Fixes#9698
Otherwise this would complete
`git --exec-path=foo`, by running `complete -C"'' --exec-path=foo"`,
which would print "--exec-path=foo", and so it would end as
`git --exec-path=--exec-path=foo` because the "replaces token" bit was
lost.
I'm not sure how to solve it cleanly - maybe an additional option to
`complete`?
Anyway, for now this
Fixes#9538.
After deleting a history item with
history delete --exact --case-sensitive the-item
it is still reachable by history search until the shell is restarted.
Let's fix this by saving history after each deletion. The non-exact variants
of "history delete" already do this. I think this was just an oversight
owed to the fact that hardly anyone uses "--exact" (else we would surely
have changed it to not require an explicit "--case-sensitive").
`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.
