This binding is akin to ForwardSingleChar but it is "passive" in that is not
intended to affect the meta state of the shell: autocompletions are not accepted
if the cursor is at the end of input and it does not have any effect in the
completions pager.
Currently, we expand command-abbrs (those with `--position command`) after `if`, but not after `command` or `builtin` or `time`:
```fish
abbr --add gc "git checkout"
```
will expand as `if gc` but not as `command gc`.
This was explicitly tested, but I have no idea why it shouldn't be?
The incorrect order of operations was being used since && binds tighter than ||
in rust (as with most sane languages).
Under Linux, EAGAIN == EWOULDBLOCK so this would always succeed in the case of a
non-blocking fd without making the call to make_fd_nonblocking().
Comparing to the 3.7.0 C++ code, it looks like this was an oversight introduced
in the migration to rust.
In particular, this allows restoring the terminal on crashes, which is
feasible now that we have the panic handler. Since std::process::exit() skips
destructors, we need to reshuffle some code. The "exit_without_destructors"
semantics (which std::process::exit() als has) was mostly necessary for C++
since Rust leaks global variables by default.
When fish crashes due to a panic, the terminal window is closed. Some
terminals keep the window around when the crash is due to a fatal signal,
but today we don't exit via fatal signal on panic.
There is the option to set «panic = "abort"» in Cargo.toml, which
would give us coredumps but also worse stacktraces on stderr.
More importantly it means that we don't unwind, so destructors are skipped
I don't think we want that because we should use destructors to
restore the terminal state.
On crash in interactive fish, read one more line before exiting, so the
stack trace is always visible.
In future, we should move this "read one line before exiting" logic to where
we call "panic!", so I can attach a debugger and see the stacktrace.
Looks like "add_custom_command(OUTPUT ...)" assumes the dependencies are
correct which is not always true. We can use "add_custom_target" to always
re-run Cargo.
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.
This was a misunderstanding, the OBS tumbleweed builds build from a tarball that's pushed manually.
We no longer use corrosion so this dependency is unused.
This reverts commit bdde2b2b35.
Fixes#10391
The current version of serial_test we use (0.4.0)
depends on parking_lot 0.10.2 which in turn
depends on lock_api 0.3.4.
This version of lock_api is vulnerable to [RUSTSEC-2020-0070](https://rustsec.org/advisories/RUSTSEC-2020-0070)
This was patched in lock_api 0.4.2 but we need to update serial_test
to get the update.
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.
A long standing issue is that bindings cannot mix special input functions
and shell commands. For example,
bind x end-of-line "commandline -i x"
silently does nothing. Instead we have to do lift everything to shell commands
bind x "commandline -f end-of-line; commandline -i x"
for no good reason.
Additionally, there is a weird ordering difference between special input
functions and shell commands. Special input functions are pushed into the
the queue whereas shell commands are executed immediately.
This weird ordering means that the above "bind x" still doesn't work as
expected, because "commandline -i" is processed before "end-of-line".
Finally, this is all implemented via weird hack to allow recursive use of
a mutable reference to the reader state.
Fix all of this by processing shell commands the same as both special input
functions and regular chars. Hopefully this doesn't break anything.
Fixes#8186Fixes#10360Closes#9398
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.
Multiline search strings are weirdly broken (inserting control characters
in the command line) and probably not very useful anyway.
On the other hand I often want to compose a multi-line command
from single-line commands I ran previously.
Let's support this case by limiting the initial search string to the current
line; and replace only that line.
Alternatively this could operate on jobs (that is, replace a surrounding
"foo | bar") instead of using line boundaries.
