This allows terminals like foot and kitty to
* scroll to the previous/next prompt with ctrl-shift-{z,x}
* pipe the last command's output to a pager with ctrl-shift-g
Kitty has existing fish shell integration
shell-integration/fish/vendor_conf.d/kitty-shell-integration.fish which we
can simplify now. They keep a state variable to decide which of prompt start,
command start or command end to output. I think with our implementation
this is no longer necessary, at least I couldn't reproduce any difference.
We also don't need to hook into fish_cancel or fish_posterror like they do;
only in the one place where we actually draw the prompt.
As mentioned in the above shell integration script, kitty disables reflow
when it sees an OSC 133 marker, so we need to do it ourselves,
otherwise the prompt will go blank after a terminal resize.
Closes#10352
If I type
$ echo $SOME_VARIABLE_WIHT_A_TYPO
$ set -S SOME_VARIABLE_WIHT
and press tab, I'm always extremely surprised that this completes to
$ set -S fish_history
which is because $history[1] contains the typo'd variable name. I don't
think anyone intends to filter by that last 3-4 history items, so let's
remove this pitfall.
Note that I usually hit this scenario with undefined variables, not necessarily
typos.. "set -S" is usually redundant but it's still quite nice in this case,
to rule out any weird empty strings/empty lists.
Similar to 20bbdb68f (Set terminal title unconditionally, 2024-03-30).
While at it, get rid of a few unnecessary guards (we are never called from
a command substitution, so the check only adds confusion).
I'm not sure if it's worth supporting a terminal that mishandles unknown OSC
and CSI sequences. Better to fix the terminal. Note that there are Emacs
terminals available that don't have this problems; for example "vterm".
See the changelog additions for user-visible changes.
Since we enable/disable terminal protocols whenever we pass terminal ownership,
tests can no longer run in parallel on the same terminal.
For the same reason, readline shortcuts in the gdb REPL will not work anymore.
As a remedy, use gdbserver, or lobby for CSI u support in libreadline.
Add sleep to some tests, otherwise they fall (both in CI and locally).
There are two weird failures on FreeBSD remaining, disable them for now
https://github.com/fish-shell/fish-shell/pull/10359/checks?check_run_id=23330096362
Design and implementation borrows heavily from Kakoune.
In future, we should try to implement more of the kitty progressive
enhancements.
Closes#10359
To do so add an ad-hoc "commandline --search-field" to operate on pager
search field.
This is primarily motivated because a following commit reuses the
fish_clipboard_paste logic for bracketed paste. This avoids a regression.
Unfortunately on Debian "open" is a symlink to "openvt", and there's
no way from outside to tell.
This prevents fish from failing because no browser could be found.
Today fish_cursor_selection_mode controls whether selection mode includes
the cursor. Since it's by default only used for Vi mode, perhaps use it to
also decide whether it should be allowed to select one-past the last character.
Not allowing to select to select one-past the last character is much nicer
in Vi mode. Unfortunately Vi mode sometimes needs to temporarily select
past end (using forward-single-char and such), so reset fish_cursor_selection_mode
for the duration of the binding.
Also fix other things like cursor placement after yank/yank-pop.
Closes#10286Closes#3299
We have
bind --preset -M $mode --sets-mode paste \e\[200~ __fish_start_bracketed_paste
Commit c3cd68dda (Process shell commands from bindings like regular char
events, 2024-03-02) made it so __fish_start_bracketed_paste is no longer
executed before the bind mode is updated.
This is a long-awaited fix but it broke __fish_start_bracketed_paste's
assumption that $fish_bind_mode is the mode before we entered paste mode.
This means we never exit paste mode.
Work around that. I forgot about this issue because I already replaced our
bracketed paste handling on my fork.
Today,
bind foo "commandline -f expand-abbr; commandline -i \n"
does not work because this
1. enqueues an expand-abbr readline event
2. "commandline -i" inserts \n
3. processes the expand-abbr readline event
Since there is no abbreviation on the new line, this doesn't do anything.
PR https://github.com/fish-shell/fish-shell/pull/9398 would fix this
particular instance however it does not fix the issue that "commandline -i"
is run before the expand-abbr is processed by the reader. This is harmless
here but there would be a problem if "commandline" tried to read commandline
state that was created by a preceding command.
It's not super clear to me whether the above binding should work as one
would naively expect. That would imply that "commandline" would need to
drain all input events (at least all synthetic ones) from the input queue,
to ensure it sees the current state.
Fortunately the parent commit makes it so if we separate them
bind foo "commandline -f expand-abbr" "commandline -i \n"
both will be separate events and the commandline state will be synced after
each of them. This fixes abbreviation expansion here.
Also, we can now mix readline cmds and shell commands, which makes it shorter.
Most chat programs I found use Shift+Return to insert a newline while plain
Return sends the message. One user reported having only tried Shift+Return
and not knowing about Alt+Return.
No release notes yet because this only works on a very small number of
terminals. Once we enable CSI u, this should work on most modern terminals.
Unless the editor changed to a different file for some reason.
Note that the Kakoune integration uses -always to export the cursor even if
the user temporarily suppressed hooks - possibly a "fish_indent" hook.
One of the things that keep me from using Vi mode is that it doesn't define an
insert-mode shortcut to accept autosuggestions. Let's use Control-N because
that Vim key is the closest equivalent.
Closes#10339
