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
enum selection_scroll_direction is used when extending a selection by
auto-scrolling the terminal content while the mouse is outside the
grid.
What we want is enum selection_direction.
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
On some platforms, TIOCSWINSZ has a very large value, >
0x80000000.
On some platforms, the `request` argument to `ioctl(3)` is an `int`.
For platforms where both of the above is true, gcc will warn (and
error out if compiled with `-Werror`) on:
ioctl(fd, TIOCSWINSZ, ...)
To silence this warning, we need to cast `TIOCSWINSZ` to an
integer.
However, doing this on platforms where `request` is an `unsigned long`
will result in `TIOCSWINSZ` being sign-extended (and thus we end up
with an invalid value).
It seems that casting to `unsigned int` works in both cases; it
silences the long -> int conversion warning, while also preserving the
correct value in all cases.
* 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.
Bind to xdg-shell version 2 if available, as this enables us to
track our window’s ‘tiled’ state in the ‘configure’ events.
This in turn allows us to stash the ‘old’ window size when being
tiled, to be used again when restoring the window size when un-tiled.
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
Assume it could be a copy-paste typo. We should check PRIMARY, not
CLIPBOARD. Without this fix, we can't use PRIMARY until we copy anything
to CLIPBOARD.
The state after this function is an intermediate state and isn’t
necessarily valid.
This sixels needs to be ‘reflowed’ to ensure a valid state. This is
something that should be done by the caller after the text grid has
been reflowed and the sixel coordinates have been re-mapped to the new
grid.
TODO: can/should we update the sixel cols/rows in sixel_reflow()
instead?
This function loops the list of sixels, and discards those that would
be scrolled out if the grid offset is moved forward by the specified
number of rows.
The criteria is when the rebased row value is less than the number of
rows to scroll.
A rebased row number is a zero-based number starting at the beginning
of the scrollback. Thus, when scrolling 5 rows, rows with a rebased
row number between 0-4 will be scrolled out.
For performance reasons, we used to break out of the loop as soon as a
row number *larger* than the scroll count.
This however does not work. The sixels are sorted by their *end*
row. While this works in most cases (think images outputted in the
shell in the normal screen), it doesn’t always.
In the alt screen, where applications can print images just about
anywhere, it is possible to have *any* start row number anywhere in
the sixel list. Just as long as their *end* row numbers are sorted.
For example, a huuuge sixel that covers the entire scrollback. This
sixel will naturally be first in the list (and thus sixel_scroll_up()
will visit it *last*, since it iterates the list in reverse), but
should still be destroyed when scrolling.
