To work around terminal bugs.
The flag "keyboard-protocols" defaults to "on" and enables keyboard protocols,
but can be turned off by setting "no-keyboard-protocols".
This has downsides as a feature flag - if you use multiple terminals and
one of them can't do it you'll have to disable it in all,
but anything else would require us to hook this up to env-dispatch,
and ensure that we turn the protocols *off* when the flag is disabled.
Since this is a temporary inconvenience, this would be okay to ask
zellij and Jetbrains-with-WSL users.
I'm running fish 4.0b1 locally and I tried running `help abbr` and
browsing the docs. I noticed one example which wasn't formatted
correctly.
I'm not too familiar with rst, but based on looking at the file, it
seems that this is how example code should be represented.
(cherry picked from commit d47a4899b4179addaedd73f18cc1219bb6d9564a)
alt-{left,right} move in the directory history (like in browsers).
Arrow keys can be inconvenient to reach on some keyboards, so
let's alias this to alt-{b,f}, which already have similar behavior.
(historically the behavior was the same; we're considering changing
that back on some platforms).
This happens to fix alt-{left,right} in Terminal.app (where we had
a workaround for some cases), Ghostty, though that alone should not
be the reason for this change.
Cherry-picked from commit f4503af037cf596f6dc4c2b2e39df703e3fd6d07.
Closes#11105
Comments by macOS users have shown that, apparently, on that platform
this isn't wanted.
The functions are there for people to use,
but we need more time to figure out if and how we're going to bind
these by default.
For example, we could change these bindings depending on the OS in future.
This reverts most of commit 6af96a81a8c6ff5e632d4dda7448f5f01d7a5d35.
Fixes#10926
See #11107
This can no longer be overridden, which means we have a broken "test"
target now. Instead, you need to call "make fish_run_tests".
Blergh.
Fixes#11116
(cherry picked from commit 8d6fdfd9deb78545ecbf2a2eabd90aeb7cbaf78e)
To check:
```fish
fish_config theme choose None
set -g fish_pager_color_selected_completion blue
```
Now the selected color will only apply to the parentheses
Missed in 43e2d7b48c21d1377c2bd34b3b2ef9c0016a38e4 (Port pager.cpp)
(cherry picked from commit 6c4d658c15e258e48cce4874cb638c5d23522051)
The version where a feature became the default is now described inline,
to make it a single source of truth. I could have fixed the other
section where this was described, but this seemed easier.
I also removed a few details that seem no longer relevant.
(cherry picked from commit 064d867873b96989fc5736a394d9264205905f7e)
This documents some non-argument options for the window and panes
commands. The choice of what to document is somewhat arbitrary,
this commit is biased towards options that I find confusing or
misleading without documentation (is `-a` "all" or "after"?)
and the command that seem more useful to me.
I also didn't cover the options that would be covered by
#10855 (though this PR can be used independently). I'm not
sure how much difference this made, it might not matter at
all.
(cherry picked from commit f241187c4a47bae2016da78ef2c6b2b7b5345747)
These dynamic completions are exhaustive, but not as well-documented or
as ergonomic as the manual completions. So, any manual completions
should override them.
(cherry picked from commit 183e20cc3a60bbf93f50d9bf35a68dab665208e6)
For example, `tmux shell<tab>` now completes to `if-shell` and
`run-shell`, though no additional information is provided.
(cherry picked from commit 27e5ed7456ff6faa59c747ee3cfb0f95850d6ee5)
If you don't care about file paths containing '=' or ':', you can
stop reading now.
In tokens like
env var=/some/path
PATH=/bin:/usr/local/b
file completion starts after the last separator (#2178).
Commit db365b5ef8 (Do not treat \: or \= as file completion anchor,
2024-04-19) allowed to override this behavior by escaping separators,
matching Bash.
Commit e97a4fab71 (Escape : and = in file completions, 2024-04-19)
adds this escaping automatically (also matching Bash).
The automatic escaping can be jarring and confusing, because separators
have basically no special meaning in the tokenizer; the escaping is
purely a hint to the completion engine, and often unnecessary.
For "/path/to/some:file", we compute completions for "file" and for
"/path/to/some:file". Usually the former already matches nothing,
meaning that escaping isn't necessary.
e97a4fab71 refers us to f7dac82ed6 (Escape separators (colon and
equals) to improve completion, 2019-08-23) for the original motivation:
$ ls /sys/bus/acpi/devices/d<tab>
$ ls /sys/bus/acpi/devices/device:
device:00/ device:0a/ …
Before automatic escaping, this scenario would suggest all files from
$PWD in addition to the expected completions shown above.
Since this seems to be mainly about the case where the suffix after
the separator is empty,
Let's remove the automatic escaping and add a heuristic to skip suffix
completions if:
1. the suffix is empty, to specifically address the above case.
2. the whole token completes to at least one appending completion.
This makes sure that "git log -- :!:" still gets completions.
(Not sure about the appending requirement)
This heuristic is probably too conservative; we can relax it later
should we hit this again.
Since this reverts most of e97a4fab71, we address the code clone
pointed out in 421ce13be6 (Fix replacing completions spuriously quoting
~, 2024-12-06). Note that e97a4fab71 quietly fixed completions for
variable overrides with brackets.
a=bracket[
But it did so in a pretty intrusive way, forcing a lot of completions
to become replacing. Let's move this logic to a more appropriate place.
---
Additionally, we could sort every whole-token completion before every
suffix-completion. That would probably improve the situation further,
but by itself it wouldn't address the immediate issue.
Closes#11027
(cherry picked from commit b6c249be0c4f075a9e7d65f94fd1677da2c58e72)
Mainly to make the next commit's diff smaller. Not much functional
change: since file completions never have the DONT_SORT flag set,
these results will be sorted, and there are no data dependencies --
unless we're overflowing the max number of completions. But in that
case the whole-token completions seem more important anyway.
(cherry picked from commit 0cfc95993a8e79de108cdc4970a623b746e34c04)
Commit 798527d79a (completions: fix double evaluation of tokenized
commandline, 2024-01-06) fixed some completions such as the "watchexec"
ones by adding "string escape" here:
set argv (commandline -opc | string escape) (commandline -ct)
This fixed double evaluation when we later call `complete -C"$argv"`.
Unfortunately -- searching for "complete -C" and
"__fish_complete_subcommand" -- it seems like that commit missed some
completions such as sudo. Fix them the same way.
Alternatively, we could defer expansion of those arguments (via
--tokens-raw), since the recursive call to completion will expand
them anyway, and we don't really need to know their value.
But there are (contrived) examples where we do want to expand first,
to correctly figure out where the subcommand starts:
sudo {-u,someuser} make ins
By definition, the tokens returned by `commandline -opc` do not
contain the token at cursor (which we're currently completing).
So the expansion should not hurt us. There is an edge case where
cartesian product expansion would produce too many results, and we
pass on the unexpanded input. In that case the extra escaping is very
unlikely to have negative effects.
Fixes # 11041
Closes # 11067
Co-authored-by: kerty <g.kabakov@inbox.ru>
We capture the process already, and we use argv by reference for the
other cases.
argv can be big, and this reduces allocations and thereby memory usage
and speed.
E.g. `set -l foo **` with 200k matches has 25% reduced memory usage
and ~5% reduced runtime.
Wgetopt needs a ":" at the beginning to turn on this type of error.
I'm not sure why that is now, and we might want to change it (but tbh
wgetopt could do with a replacement anyway).
Fixes#11049
