Previously, foot would not accept the following:
[key-bindings]
minimize=Escape
minimize=Escape
Now it does. I.e. key combos in the action being updated are ignored
when detecting collisions.
The example above is contrived; a real world example could be to
remove certain combos from an action with multiple combos; perhaps to
free up a combo for another action. Example:
[search-bindings]
cancel=Escape
This would previously cause an error since `cancel=Control+g Escape`
by default.
Closes#233
This fixes an issue where foot --server did not exit on SIGINT. This
happened because we never returned out from fdm_poll(), and thus we
never saw ‘aborted’ being set.
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.
We call term_arm_blink_timer() from render_cell(), which runs in
multiple threads.
This caused multiple blink timer FDs to be created and registered with
the FDM, later causing read failures after one of those FDs had been
closed again.
This rarely happened under normal circumstances, but was easy to
trigger when the whole screen was full of blinking text.
As a small optimization, we don’t bother taking the lock if the timer
FD already is valid.
This is safe, because:
1) If the timer FD isn’t valid, we take the lock and then call
term_arm_blink_timer(), which again checks if the FD is already
valid.
2) The blink timer FD cannot be closed while we’re rendering cells. It
is only disabled in the FDM callback, which cannot execute while
we’re rendering.
When checking if we should allow a single-width character double-width
glyph to overflow into the next cell, require the next cell to either
be empty, or contain a space.
Closes#203
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.
