When we print a character to the grid, we must also update its OSC-8
state if an OSC-8 URI is currently active.
For double-width characters, this was only being done for the first
cell.
This causes the labels in URL mode to be off, as the link was
effectively chopped up into multiple pieces.
Closes#2179
This makes the "uppercase hint character inserts selected text"
behavior added in #1975 configurable, as it can have unexpected
behavior for some users.
It defaults to "on", preserving the new behavior of `foot`, after
Fixes#2159.
Some of the value_to_*() functions wrote directly to the output
variable, even when the value was invalid. This often resulted in the
an actual configuration option (i.e. a member in the config struct) to
be overwritten by an invalid value.
For example, -o initial-color-theme=0 would set
conf->initial_color_theme to -1, resulting in a crash later, when
initializing a terminal instance.
This patch adds the IPC infrastructure necessary to propagate
SIGUSR1/SIGUSR2 from a footclient process to the server process.
By targeting a particular footclient instance, only that particular
instance changes theme. This is different from when targeting the
server process, where all instances change theme.
Closes#2156
When sending SIGUSR1/SIGUSR2 to a server process, all currently
running client instances change their theme. But before this patch,
all future instances used the original theme. With this patch, the
server owned config object is updated with the selected theme, thus
making new instances use the same theme as well.
This ensures applications don't mistake foot for another terminal
emulator. Not that applications _should_ rely on environment
variables, but some do anyway...
When selecting 16-bit surfaces, we set pixman_fmt_without_alpha twice,
and never set pixman_fmt_with_alpha.
This caused 10-bit surfaces to be used instead, since it checks if
pixman_fmt_with_alpha has been overridden or not.
Before this patch, SIGUSR1 toggled between [colors] and
[colors2].
Now, SIGUSR1 changes to [colors], regardless of what the current color
theme is, and SIGUSR2 changes to [colors2].
Closes#2144
Sway used to have an issue where unmapping a subsurface did not damage
the surface below (https://github.com/swaywm/sway/issues/6960).
This has been fixed for quite some time now, so let's remove the
quirk.
Before this patch, the grid content was *always* centered when the
window was maximized or fullscreened, regardless of how the user had
configured padding.
Now, the behavior is controlled by the 'pad' option. Before this
patch, the syntax was
pad MxN [center]
Now it is
pad MxN [center|center-when-fullscreen|center-when-maximized-and-fullscreen]
The default is "pad 0x0 center-when-maximized-and-fullscreen", to
match current behavior.
Closes#2111
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
