These (non-css) cursor shapes were added to the cursor-shape-v1
protocol in wayland-protocols 1.42.
We don't need (or use them at all) internally, but add them to the
list we use to translate from shape names to shape enums. This allows
users to set a custom shape (via OSC-22), while still using server
side cursors (i.e. no need to fallback to client-side cursors).
If we try to set a shape not implemented by the server, we get a
protocol error and foot exits. This is bad.
So, make sure we don't do that:
1. First, we need to explicitly bind v2 if implemented by the server
2. Track the bound version number in the wayland struct
3. When matching shape enum, skip shapes not supported in the
currently bound version of the cursor-shape protocol
Currently, if the following occurs:
1. foot has AxB size
2. Compositor sends CxD size
3. foot detects a resize, acks and saves CxD, but doesn't redraw immediately
4. Compositor sends CxD size again (due to a toplevel state array
change, for example)
Then foot will detect no resize occurred, and will do an "empty"
commit immediately.
In this particular case that's wrong, since we're effectively
acking+committing the initial AxB size.
Fix by only doing the immediate commit if there's no size
change **and** there's no pending refresh.
Note: normally, we'd resize and refresh+commit immediately, but if
we're waiting for a frame callback, then the refresh+commit will be
delayed (i.e. scheduled). This is what we're checking here.
Closes#2105
The version bump was done since we now use XKB_VMOD_NAME_*; macros
added in libxkbcommon 1.8.0.
Not all distros have updated libxkbcommon yet (read: Debian). Since
it's fairly easy to work around, let's do that.
Closes#2103
Before this patch, we just called c32width(), which only works on
actual codepoints. If the last printed character is a "combining"
character, i.e. a key into our lookup table for multi-codepoint
graphemes, we need to lookup the grapheme and pick the width from
there.
See https://gitlab.com/AutumnMeowMeow/jexer/-/issues/119#note_2499712901
Before this, we only applied custom selection colors, if *both* the
selection bg and fg had been set.
Since the options are already split up into two separate options, and
since it makes sense to at least be able to keep the foreground colors
unchanged (i.e. only setting the selection background), let's allow
only having one of the selection colors set.
Closes#1846
This adds supports for 16-bit surfaces, using the new
PIXMAN_a16b16g16r16 buffer format. This maps to
WL_SHM_FORMAT_ABGR16161616 (little-endian).
Use the new 16-bit surfaces by default, when
gamma-correct-blending=yes.
When parsing an OSC-11 without an alpha value (i.e. standard OSC-11,
not rxvt's extended variant), restore the alpha value from the
configuration, rather than keeping whatever the current alpha is.
This fixes an issue where protocol errors aren't reported. I'm
guessing the read succeeds, but that prepare_read() _also_ succeeds
immediately, since there aren't any events to dispatch (only log the
protocol error).
By calling dispatch unconditionally, we ensure any error messages are
printed. Then we proceed to loop prepare_read() + dispatch_pending()
until the queue is empty.
In copy-regex/show-urls-copy mode, if the last input character was
uppercase, copy the selection to the clipboard _and_ paste it. This is
useful for taking a file path from a command output:(log, git, test
failure, etc.) and using it in another command.
This is inspired by the behavior of copy mode in wezterm:
https://wezterm.org/quickselect.html
I could have made it check every character in the hint, but it seemed
fine to assume that if the last character was uppercase, the user
wanted this behavior.
Closes#1975.
When set to 'auto', use 10-bit surfaces if gamma-correct blending is
enabled, and 8-bit surfaces otherwise.
Note that we may still fallback to 8-bit surfaces (without disabling
gamma-correct blending) if the compositor does not support 10-bit
surfaces.
Closes#2082
When set to 'auto', use 10-bit surfaces if gamma-correct blending is
enabled, and 8-bit surfaces otherwise.
Note that we may still fallback to 8-bit surfaces (without disabling
gamma-correct blending) if the compositor does not support 10-bit
surfaces.
Closes#2082
This option selects which color theme to use by default. I.e. at
startup, and after a reset.
This is useful with combined theme files, where a single file defines
e.g. both a dark and light version of the theme.
* Recognize 'CSI ? 996 n', and respond with
- 'CSI ? 997 ; 1 n' if the primary theme is active
- 'CSI ? 997 ; 2 n' if the alternative theme is actice
* Implement private mode 2031, where changing the color
theme (currently only possible via key bindings) causes the terminal
to send the same CSI sequences as above.
In this context, foot's primary theme is considered dark, and the
alternative theme light (since the default theme is dark).
Closes#2025
* color-theme-switch-1: select the primary color theme
* color-theme-switch-2: select the alternative color theme
* color-theme-toggle: toggle between the primary and alternative color themes
This section defines an alternative color theme. The keys are the same
as in the 'colors' section, as are the default values.
Values are *not* inherited from 'colors'. That is, if you set a value
in 'colors', but not in 'colors2', it is *not* inherited by 'colors2'.
