While doing a scrollback search, the pre-edit string should be
rendered in the search box, not in the grid.
Note that we don’t yet support IME in scrollback search mode. This
patch simply prevents the pre-edit text being rendered in the grid,
in the “background”, while searching.
We may want to be able to enable/disable IME run-time, even though we
have received an ‘enter’ IME event.
This enables us to do that.
Also add functions to enable/disable IME on a per-terminal instance
basis.
A terminal may have multiple seats focusing it, and enabling/disabling
IME in a terminal instance enables/disables IME on all those seats.
Finally, the code to enable IME is simplified; the *only* surface that
can ever receive ‘enter’ IME events is the main grid. All other
surfaces are sub-surfaces, without their own keyboard focus.
The position calculated by render_grid() may be -1,-1 if the cursor is
currently hidden.
This fixes a crash when trying to input IME while the cursor is
hidden.
This is done by allocating cells for the pre-edit text when receiving
the text-input::done() call, and populating them by converting the
utf-8 formatted pre-edit text to wchars.
We also convert the pre-edit cursor position to cell positions (it can
cover multiple cells).
When rendering, we simply render the pre-edit cells on-top off the
regular grid. While doing so, we also mark the underlying, “real”,
cells as dirty, to ensure they are re-rendered when the pre-edit text
is modified or removed.
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
