For the case
```
bind \et "commandline -i 1" "commandline -i 2"
```
the order of execution of the commands is now in-order.
Note that functions codes are prepended to the queue in reverse order, so they
will be executed in-order. This should allow all bindings of the form
```
bind \et beginning-of-line force-repaint
```
to remain unchanged.
Using builtin `commandline -f`, one would expect to have commands executed in
the order that they were given. This motivates the change to a queue.
Unfortunately, fish internals still need lookahead_list to act as a stack. Add
and rename functions to support both cases and have lookahead_list as
a std::deque internally.
This code is delicate, and we should probably dog-food this in nightly for
a while before the next-minor release.
Fixes#1567
Binds with the same sequence in multiple modes was not working right.
Fix up the implementation to propagate modes everywhere as necessary.
This means that `bind` will properly list distinct binds with the same
sequence, and `bind -e` will take mode into account properly as well.
Note that `bind -e seq` now assumes the bind is in the default bind
mode, whereas before it would erase the first binding with that sequence
regardless of mode.
`bind -e -a` still erases all binds in all modes, though `bind -M mode
-e -a` still only erases all binds in the selected mode.
When a key is bound to a fish function, if that function invokes
`commandline`, it gets a stale copy of the commandline. This is because
any keys passed to `self-insert` (the default) don't actually get added
to the commandline until a special character is processed, such as the
R_NULL that gets returned after running a binding for a fish command.
To fix this, don't allow fish commands to be run for bindings if we're
processing more than one key. When a key wants to invoke a fish command,
instead we push the invocation sequence back onto the input, followed by
an R_NULL, and return. This causes the input loop to break out and
update the commandline. When it starts up again, it will re-process the
keys and invoke the fish command.
This is primarily an issue with pasting text that includes bound keys in
it. Typed text is slow enough that fish will update the commandline
between each character.
---
I don't know of any way to write a test for this, but the issue can be
reproduced as follows:
> bind _ 'commandline -i _'
This binds _ to a command that inserts _. Typing the following works:
> echo wat_is_it
But if you copy that line and paste it instead of typing it, the end
result looks like
> _echo wat_isit
With this fix in place, the pasted output correctly matches the typed
output.
is specified before Y, then Y will never be invoked because X will
always get there first. Now instead we order bindings in descending
order by length, so that we always test the binding before any others that
prefixes it. Fixes#1283.
Closes: https://github.com/fish-shell/fish-shell/issues/1060
'ansi' should always be present (tested on Solaris, Linux, FreeBSD,
Darwin).
Also overrides TERM so that other programs behave consistently e.g.
fish_pager.
The error message makes no specific mention of terminfo or termcap as
these vary across operating systems.
(r+ @ridiculousfish with thanks)
On FreeBSD, compilation complains that "this file includes
<sys/termios.h> which is deprecated, use <termios.h> instead". On Linux
and FreeBSD, <sys/termios.h> literally just pulls in <termios.h>. On OS
X and Solaris, <termios.h> pulls in <sys/termios.h>.
<termio.h> doesn't exist on FreeBSD or Mac OS X, and on Linux is marked
as deprecated and just includes <termios.h>. It does exist on Solaris,
but no `struct termio` is ever actually used in the codebase.
