TerminalUI::suspend() is responsible for undoing all Kakoune's modifications to
the terminal state, actually suspending the process, then re-applying all the
modifications after Kakoune wakes back up.
Previously, the "undo" and "reapply" steps for termios settings were both after
the suspend point, so on some platforms they were incorrect when the user
arrived back at the shell prompt.
Now, the termios "undo" step is back before the suspend point, and the undo and
reapply steps should be in exactly reversed order.
Fixes#3488.
In terminals that support it, this sequence causes the terminal to not redraw
*its* output until the application has finished, reducing redraw flickering.
The sequence is defined in:
https://gitlab.com/gnachman/iterm2/-/wikis/synchronized-updates-spec
...and is apparently also supported by kitty and libVTE.
Fixes#3482.
insert blank seems to behave differently between terminals and would
be less efficient because it still has to shift all following characters
(that we will overwrite anyway).
Fixes#3437
Diff against known state and insert/erase relevant lines.
Erase everything first to avoid insertion invalidating lines that
get out of the terminal at bottom.
This should reduce flicker, by avoiding transient states where
info/menu windows are not displayed, and paves the way for proper
diffing of the screen.
Log error to debug buffer and Change the 'waiting for shell' face
to 'Error'.
Update the 'waiting for shell' message when the shell has exited
but Kakoune is still waiting on stdin/stdout/stderr to be closed.
Those fifos are accessible during %sh{...} blocks, the command fifo
executes commands written to it once the write end side is closed
(multiple open/write/close sequences are supported), the response
fifo is a simple helper fifo available to write response back to
the shell process
An example use of this feature is to request some list options
content from without being limited by the environment size:
```
%sh{
echo "echo -to-file $kak_response_fifo -quoting shell -- %opt{some_list}" > $kak_command_fifo
eval "set -- $(cat $kak_response_fifo)"
}
```
If a %sh{} script refers to any variables multiple times they are all multiply
included in the environment. Example: if a %sh{} invocation refers to
${kak_buffile} 5 times, the environment will have "kak_buffile=..." repeated 5
times and so on. This repetition happens for each multiply used variable that
is passed into the environment.
The variable should, of course, be only passed into the environment once. This
commit should fix this issue.
The real technical limit is with lines bigger than 2 GiB and buffers
with more than 2 Gi lines, refactor buffer loading to make it possible
to load those files.
Fix an overflow with the hash_data function at the same time
This fixes an issue where completion would still be provided after
the closing character of a token, which could then get frustrating
combined with auto-insertion of completions.
For example, inserting `%{<newline>}` for a command-completed token
(such as the commands for a hook) would still trigger completion right
after the `}` and that completion would get auto-inserted **replacing**
that closing `}`.
Do not use a shared kakoune/ directory for all users to avoid the
complexity of having to set the sticky bit on that dir, resolve the
session directoy only once by using a static variable and an
immediately evaluated lambda.
This fixes an annoyance whenver using `su` and having Kakoune refuse
to start due to XDG_RUNTIME_DIR still being set.
For historical reasons, mouse events represent keyboard modifiers as a bitfield,
but keyboard events represent modifiers as a bitfield-plus-one. For example, a
mouse event with an Alt modifier will use the value 4, but a keyboard event will
use the value 5.
Previously, I refactored the parse_mask() helper to do the subtraction itself,
instead of requiring the caller to do it. This made keyboard-event decoding much
cleaner, but I didn't realise it broke mouse-event decoding. Now the subtraction
is done only for keyboard events.
Fixes#4176.
In some cases, it may be difficult to easily spot the area out of the buffer
(bad color scheme, small font, superimposed windows).
This patch adds two ncurses ui_options to bypass this problem:
- `ncurses_padding_char`, to configure the padding character,
- `ncurses_padding_fill`, to indicate whether to fill the padding line
(or to display a single character).
The default config is the legacy one (a single "~").
- Add the Narrow No-Break SPace (0x202F, NNBSP) to the list of handled
spaces in the show-whitespace highlighter.
- Do not add an aditional option, just handle it like NBSP, with the same highlight character.
Quote by wrapping in quotes if we are replacing the whole token,
using backspaces if the completion only adds to it.
This ensure that the inserted completion will be correctly parsed
once validated.
Fixes#4121
Kakoune now knows about all the keypad keys listed in:
https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-PC-Style-Function-Keyshttps://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-VT220-Style-Function-Keys
The VT220-style encodings are used to for modified numeric keys when NumLock is
off. For example, consider the 8/Up key:
| Modifiers | Sequence | Notes |
|-----------------|-------------|-------------------|
| Unmodified | CSI A | Ordinary up arrow |
| Shift | SS3 2 x | Shift-8 |
| NumLock | 8 | Ordinary 8 |
| Shift + NumLock | CSI 1 ; 2 A | Shift-Up |
Note that even though the terminal distinguishes between keypad and regular keys,
Kakoune maps keypad keys onto regular keys - keypad Enter is still <ret>, it
just supports more modifiers than the regular Enter key.
It's useful for parsing modifier masks in all kinds of sequences, not just CSI
sequences. Also, since the modifier mask always has "1" as "no modifiers",
do the subtraction inside parse_mask() instead of when calling it.
This avoids 100% CPU usage when we have pending fifo input while running
a shell process, as we will not end-up busy looping in pselect but not
reading the available data due to being only processing urgent events.
When a replaced buffer range atom was starting exactly at the
location we wanted to split onto the code would split *after*
that atom instead of before.
Fixes#4052
