All alt+return combos mapped to the same escape sequence as alt+return
itself.
With this patch, alt+<mod(s)>+return map to a standard ‘CSI 27;x;13~’
sequence.
With XKB, Shift+Tab maps to XKB_KEY_ISO_Left_Tab, not
XKB_Key_Tab. Previously, we had two different lookup tables for the
two.
The tab table was correctly populated, while the ISO-left tab
wasn’t. As a result, all Shift+Tab combos (except Shift+Tab itself)
was wrong, and resulted in the same escape sequence as Shift+Tab.
Fix by using the same table for both tab and ISO-left tab.
Closes#210
When num lock override has been enabled via “CSI?1035h” (the default),
keypad is always considered to be in ‘numerical’ mode.
This affects how keypad keys are translated to escape sequences when
Num Lock is active.
The keypad has four modes:
* Num Lock off, numerical mode
* Num Lock off, application mode
* Num Lock on, numerical mode
* Num Lock on, application mode
The keymap is identical for numerical and application mode when Num
Lock is off, meaning the keypad effectively has three different modes.
In XTerm, numerical and application mode _can_ be the same, **if** the
‘numLock’ resource is set to true (the default). It is only when
‘numLock’ is false that the application mode is actually used.
This patch changes foot to do the same. We don’t expose an option, but
do implement “CSI ? 1035”.
Closes#194
A configure event must be “committed”. In case of resizing, that means
rendering a new frame and committing that surface.
render_resize() will resize the grid and *schedule* a render
refresh. However, if one is already pending, the refresh will take a
very (relatively) long time - until the next frame callback is
received.
This poses a problem when the window is hidden, since in this case,
the frame callback *never* comes. This in turn means we fail to commit
a new surface in response to the ‘configure’ event. And that means the
compositor needs to wait for a transaction timeout before continuing.
The end effect is very slow and jerky window resizing when a hidden
foot window is being resized.
This can happen in tiled compositors, like Sway, where a window can be
tabbed (and thus invisible), but still resized when its container is
resized.
Closes#190
Don’t require NumLock to be locked. Foot has no idea _which_ modifier
the user has mapped NumLock to, meaning we really cannot require it to
be locked.
This mode can be set by client programs with the DECSET, DECRST,
XTSAVE and XTRESTORE sequences by using 27127 as the parameter.
The sequence "\E[27;1;27~" is encoded in the same way as is done by
xterm's "modifyOtherKeys" mode. Even though xterm itself never emits
such a sequence for the Escape key, many programs already have
support for parsing this style of key sequence.
There are two different escape sequences that can be used to set the
cursor blink state: ‘CSI ? 12 h/l’ and ‘CSI Ps SP q’.
Up until now, they both modified the same internal state in foot. This
meant you could enable a blinking cursor with e.g. ‘CSI ? 12 h’ and
then disable it with ‘CSI 2 SP q’.
Since the ‘CSI ? 12’ escapes are used in the civis/cnorm/cvvis
terminfo entries, applications often ended up disabling the blink
state on exit (typically be emitting ‘cnorm’), requiring users to
manually re-enable blinking.
By splitting the internal state into two separate states, we can
improve the situation.
The cursor will blink if at least one of the two have been enabled.
The setting in foot.ini sets the default state of the ‘CSI Ps SP q’
escape.
This means if the user has enabled blinking in the configuration, the
cursor will blink regardless of civis/cnorm/cvvis. Which probably is
what the user wants.
If the user has NOT enabled blinking, civis/cnorm/cvvis act as
intended: cvvis blink, civis and cnorm do not.
If an application overrides the cursor blink/style with ‘CSI Ps SP q’,
that will override the user’s setting in foot.ini. But most likely
that too is intended (for example, the user may have configured the
application to use a different cursor style). And, a well written
application will emit the ‘Se’ terminfo sequence on exit, which in
foot is defined to ‘CSI SP q’, which will reset both the style and
blink state to the user configured style/state.
Closes#218
Alt screen applications normally reflow/readjust themselves on a
window resize.
When we do it too, the result is graphical glitches/flashes since our
re-flowed text is rendered in one frame, and the application re-flowed
text soon thereafter.
We can’t avoid rendering some kind of re-flowed frame, since we don’t
know when, or even if, the application will update itself. To avoid
glitches, we need to render, as closely as possible, what the
application itself will render shortly.
This is actually pretty simple; we just need to copy the visible
content over from the old grid to the new grid. We don’t bother with
text re-flow, but simply truncate long lines.
To simplify things, we simply cancel any active selection (since often
times, it will be corrupted anyway when the application redraws
itself).
Since we’re not reflowing text, there’s no need to translate e.g. the
cursor position - we just keep the current position (but bounded to
the new dimensions).
Fun thing: ‘less’ gets corrupted if we don’t leave the cursor at
the (new) bottom row. To handle this, we check if the cursor (before
resize) is at the bottom row, and if so, we move it to the new bottom
row.
Closes#221
wl_output_release, the use of which was recently introduced, is not
available until wl_output interface version 3.
However, only wl_output version 2 was bound. This lead to protocol
errors when a display was disconnected, causing foot to terminate.
Instead, only use wl_output_release if wl_output version 3 is provided
and bound. Otherwise, just use wl_output_destroy.
Closes: https://codeberg.org/dnkl/foot/issues/219
