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.
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.
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
When converting mouse scroll events to keyboard input (in alternate
scroll mode), we need to use seat->mouse_focus, not seat->kbd_focus.
To enable this, break out key press/release handling code to a
separate function that takes an explicit term argument. Call this
function from keyboard_key(), input_repeat() and in alternate scroll
mode.
Closes#179
* Don’t de-reference the xkb context/keymap/state if we failed to
instantiate them.
* Don’t try to send a translated utf8 key sequence if the translation
failed.
* Handle xkb_compose_state_get_utf8() and xkb_state_key_get_utf8()
returning more than 64 bytes.
This _may_ fix#171.
Handle xkb_compose_table_new_from_locale() returning NULL. When this
happens, log a warning that “dead keys” will be disabled, and make
sure to never de-reference the compose table pointer.
Closes#170
When we ‘consume’ a mouse button event (i.e. when we have a shortcut
mapped to it), the event should *not* be passed on to the client
application.
In 5f64c5c335, button handling was
refactored and unfortunately introduced a regression where we once
again started passing consumed button presses to the client
application.
Fixes#168
Trackpad scroll movements are in pixels. Foot previously “translated”
these directly to line movements (i.e. a one pixel scroll event was
translated into a one line scroll).
Now we use the line height of the terminal and correctly convert
pixels to lines.
This makes the trackpad scroll speed in foot consistent with the
scroll speed in e.g. Alacritty and Kitty.
Allow a mouse binding to match even if its click count is less than
the actual click count.
If there are multiple bindings that match, use the one with the
highest click count (that less than, or equal to the actual click
count).
Closes#146
Moving the mouse outside the grid while we have an on-going selection
now starts a timer. The interval of this timer depends on the mouse’s
distance from the grid - the further away the mouse is, the shorter
interval.
On each timer timeout, we scroll one line, and update the
selection. Thus, the shorter the interval, the faster we scroll.
The timer is canceled as soon as the mouse enters the grid again, or
the selection is either canceled or finalized.
The timer FD is created and destroyed on-demand.
Most of the logic is now in selection.c. The exception is the
calculation of the timer interval, which depends on the mouse’s
position. Thus, this is done in input.c.
The scroll+selection update logic needs to know a) which direction
we’re scrolling in, and b) which *column* the selection should be
updated with.
If the mouse is outside the grid’s left or right margins, the stored
mouse column will be -1. I.e. we don’t know whether the mouse is on
the left or right side of the grid. This is why the caller, that
starts the timer, must provide this value.
The same applies to top and bottom margins, but since we already have
the scroll *direction*, which row value to use can be derived from this.
If the cursor moves above the grid top, or below the grid bottom,
while selecting text, scroll up/down the scrollback before updating
the selection.
TODO: this only scrolls when the mouse is *moved*. I.e. you can’t move
the cursor outside the grid once and for all, and then let foot
auto-scroll.
Trackpad scroll movements are in pixels. Foot previously “translated”
these directly to line movements (i.e. a one pixel scroll event was
translated into a one line scroll).
Now we use the line height of the terminal and correctly convert
pixels to lines.
This makes the trackpad scroll speed in foot consistent with the
scroll speed in e.g. Alacritty and Kitty.
Allow a mouse binding to match even if its click count is less than
the actual click count.
If there are multiple bindings that match, use the one with the
highest click count (that less than, or equal to the actual click
count).
Closes#146
The keycodes will change if the seat’s keymap changes. Make sure we
only do alternate scrolling if the seat has a keyboard, and use
the *current* layout’s keycodes for arrow up/down (instead of
the *first* layout’s).
This deprecates/renames scrollback-up/down to scrollback-up/down-page.
It also renames scrollback-up/down-half to
scrollback-up/down-half-page, and adds the new bindings
scrollback-up/down-line.
This introduces a new state to a seat's mouse struct, 'consumed'. It
is set on a mouse *press* event that is claimed by a mouse binding.
It is cleared after a mouse *release* event.
While set, *no* mouse motion or button events are sent to the client
application.
Shift is used to enable selection when the client application is
grabbing the mouse.
As such, mouse bindings *never* have Shift as a modifier, but should
still trigger when Shift is being pressed.
We shouldn't start or modify a selection if selection isn't
possible (i.e. client application is grabbing the mouse, and user
isn't holding Shift).
We also shouldn't start or modify a selection if the pointer is
outside the grid (updating an ongoing selection on motion events is an
exception to this).
This extends the "normal" bind action enum with mouse specific
actions.
When parsing key bindings, we only check up to the last valid keyboard
binding, while mouse bindings support *both* key actions and mouse
actions.
The new actions are:
* select-begin: starts an interactive selection
* select-extend: interactively extend an existing selection
* select-word: select word under cursor
* select-word-whitespace: select word under cursor, where the only
word separating characters are whitespace characters.
The old hard-coded selection "bindings" have been converted to instead
use these actions, via default bindings added to the configuration.
This simplifies the handling of mouse and keyboard bindings.
Before, the bindings where parsed *both* when loading the
configuration, and then on every keyboard enter event. This was done
since keys require a keymap to be decoded. Something we don't have at
configuration time. The idea was that at config time, we used a
default keymap just to verify the key combo strings were valid.
The following has changed:
* The bindings in the config struct is now *one* key combo per
entry. Previously, it was one *action* per entry, and each entry
had one or more key combos.
Doing it this way makes it easier when converting the binding in the
keyboard enter event (which previously had to expand the combos
anyway).
* The bindings in the config struct no longer contains any unparsed
strings.
A key binding contains a decoded 'modifier' struct (which specifies
whether e.g. ctrl, or shift, or ctrl+shift must be pressed for the
binding to be used).
It also contains a decoded XKB keysym.
* A mouse binding in the config struct is similar to a key binding,
except it contains the button, and click count instead of the XKB
key sym.
* The modifiers in the user-specified key combo is decoded at config
time, by using the pre-defined XKB constants
XKB_MOD_NAME_<modifier>.
The result is stored in a 'modifiers' struct, which is just a
collection of booleans; one for each supported modifier.
The supported modifiers are: shift, ctrl, alt and meta/super.
* The key sym is decoded at config time using
xkb_keysym_from_name(). This call does *not* depend on a keymap.
* The mouse button is decoded at config time using a hardcoded mapping
table (just like before).
* The click count is currently hard-coded to 1.
* In the keyboard enter event, all we need to do is pre-compute the
xkb_mod_mask_t variable for each key/mouse binding, and find all the
*key codes* that map to the (already decoded) symbol.
For mouse bindings, the modifiers are the *only* reason we convert
the mouse bindings at all.
In fact, on button events, we check if the seat has a keyboard. If
not, we use the mouse bindings from the configuration directly, and
simply filter out those with a non-empty set of modifiers.
