When we initially implemented the kitty notification protocol, 128
bytes was enough.
Since then, the protocol has grown, and 128 bytes is no longer enough,
resulting in a crash when you try to query the protocol:
printf "\e]99;i=123:p=?;\e\\"
Results in
#0 0x7fe4fad3dcde in __sanitizer_print_stack_trace (/usr/lib/libasan.so.8+0x13dcde) (BuildId: 38f5643355445a477f07ffa9b6a83a55c87415a0)
#1 0x561ec61454e8 in print_stack_trace ../../debug.c:20
#2 0x561ec6145550 in fatal_error ../../debug.c:28
#3 0x561ec61462d0 in xvsnprintf ../../xsnprintf.c:42
#4 0x561ec614640a in xsnprintf ../../xsnprintf.c:52
#5 0x561ec6131fe6 in kitty_notification ../../osc.c:765
#6 0x561ec6139fec in osc_dispatch ../../osc.c:1511
#7 0x561ec60fcac8 in action_osc_end ../../vt.c:614
#8 0x561ec60fe6bb in state_osc_string_switch ../../vt.c:924
#9 0x561ec60ff437 in vt_from_slave ../../vt.c:1115
#10 0x561ec6078748 in fdm_ptmx ../../terminal.c:297
#11 0x561ec5ee6ed0 in fdm_poll ../../fdm.c:483
#12 0x561ec5f344d3 in main ../../main.c:676
#13 0x7fe4f9e2777d (/usr/lib/libc.so.6+0x2777d) (BuildId: 674f3ebbcb651fbc7d1189cb300acfd7d007849a)
#14 0x7fe4f9e278bb in __libc_start_main (/usr/lib/libc.so.6+0x278bb) (BuildId: 674f3ebbcb651fbc7d1189cb300acfd7d007849a)
#15 0x561ec5e77a14 in _start (/home/daniel/src/foot/bld/debug/foot+0x4b8a14) (BuildId: 9fca511350f3745edd3546ff800a763c1957e673)
Closes#2335
We already detect if the final cursor colors (foreground/background)
are identical.
If they were, we replaced them with the default fg/bg.
Unfortunately, this can still result in an invisible cursor. For
example, if the current cell's default bg matches the current cell's
fg.
Instead, update the colors in two steps:
1. First, use the provided (cell's) fg/bg
2. If they too match, invert the cursor color
This should ensure the cursor is always visible
Closes#2323
When processing shortcuts, set seat->kbd.last_shortcut_sym. This
ensures the corresponding release event is ignored in the main mode,
if the shortcut triggered a mode exit.
For example, pressing Return in search mode would exit search mode,
and then immediately reset the search match, if the kitty keyboard
protocol mode with release events were enabled.
I'm guessing, but I'm not sure, that when I initially implemented
this, XTerm ignored shift in keypad escapes.
Testing again, it doesn't. And regardless of what XTerm does, I don't
really see any reason to exclude shift from keypad escapes.
Closes#2324
This option allows you to configure which underline style to use with
URLs.
The default is dotted. Since before this patch, URL underlines were
always plain underlines, this means the default URL underline style
has changed, from single to dotted.
Closes#2302
In 3a2eb80d83, we fixed an issue where
key *releases* triggered a selection reset, and viewport reset.
The same issue still exists in other input modes (unicode, search and
url mode); if the kitty keyboard protocol has been enabled, with
release events, any key press directed to e.g. search input handling,
will was not remembered, and the corresponding release event generated
a kitty keyboard event to the terminal application, and reset the
viewport and selection.
This means, for example, that scrollback search was unusable.
Fix by *never* doing any further (generic) key processing if an
alternate input mode is active.
Closes#2316
When writing paste data to the terminal (either interactively, or as
an OSC-52 reply), we enqueue other data (key presses, for examples, or
query replies) while the paste is happening.
The idea is to send the key press _after_ all paste data has been
written, to ensure consistency.
Unfortunately, we only checked for an on-going paste. I.e. where the
paste itself hasn't yet finished. It is also possible the paste itself
has finished, but we haven't yet flushed all the paste buffers. That
is, if we were able to *receive* paste data faster than the terminal
client was able to *consume* it. In this case, we've queued up paste
data in the terminal. These are in separate queues, and when emitting
e.g. a key press, we didn't check if all _those_ queues had been
flushed yet.
Closes#2307
The pre-apply damage thread may be running when we destroy a terminal
instance, and we need to wait for it to finish before destroying the
underlying buffer.
c291194a4e did this, but failed to
realize the thread may get re-started in the roundtrips done later in
wayl_win_destroy(); after the wait added in
c291194a4e, we unmap all
surfaces (including the main grid), and roundtrip. This means the
compositor will release the currently active buffer, and that means
_we_ will trigger the pre-apply damage thread on it. This introduces a
race, where wayl_win_destroy() may reach its shm_purge() calls before
the pre-apply damage thread has finished. That typically causes foot
to crash.
Closes#2288
Recent clang versions warn on __COUNTER__, unless compiling with
-std=c2y (which breaks other things).
"Fixes" '__COUNTER__' is a C2y extension (__COUNTER__ is used by our
UNITTEST macro).
This patch adds a new config option: colors{,2}.blur=no|yes. When
enabled, transparent background are also blurred.
Note that this requires the brand new ext-background-effect-v1
protocol, and specifically, that the compositor implements the blur
effect.
It's possible, but unlikely, that we've pushed a "pre-apply damage"
job to the renderer thread queue (or that we've pushed it, and the
a thread is now working on it) when we shutdown a terminal instance.
This is sometimes caught in an assertion in term_destroy(), where we
check the queue length is 0. Other times, or in release builds, we
might crash in the thread, or in the shutdown logic when freeing the
buffer chains associated with the terminal instance.
Fix by ensuring there's no pre-apply damage operation queued, or
running, before shutting down a terminal instance.
Closes#2263
Applications often prefix the sixel with a raster attributes (RA)
sequence, where they tell us how large the sixel is. Strictly
speaking, this just tells us the size of the area to clear, but we use
it as a hint and pre-allocates the image buffer.
It's important to stress that it is valid to emit a MxN RA, and then
write sixel data outside of that area.
Foot handles this, in _most_ cases. We didn't handle the corner case
Mx0. I.e. a width > 0, but height == 0. No image buffer was allocated,
and we also failed to detect a resize was necessary when the
application started printing sixel data.
Much of this is for performance reason; we only check the minimum
necessary. For example, we only check if going outside the
pre-allocated *column* while printing sixels. *Rows* are checked on a
graphical newline.
In other words, the *current* row has to be valid when writing
sixels. And in case of Mx0, it wasn't.
Fix by forcing a height of at least one sixel (typically 6 pixels).
Closes#2267
This fixes an issue with the kitty keyboard protocol, where 'release'
events associated with a shortcut was sent to the client application.
Example: user triggers "scroll up". We scroll up. No key event(s) are
sent to the client application. Then the user releases the keys. we
don't do any shortcut handling on release events, and so we continue
with the normal input processing. If the kitty keyboard protocol has
been enabled (and specifically, release event reporting has been
enabled), then we'll emit a 'release' escape sequence. This in itself
is wrong, since the client application never saw the corresponding
press event. But we _also_ reset the viewport. The effect (in this
example), is that it's impossible to scroll up in the scrollback
history.
Note that we don't ignore _any_ release event, only the release event
for the (final) symbol that triggered the shortcut.
This should allow e.g. modifier keys release events to be processed
normally, if released before the shortcut key.
This is somewhat important, since the client application will have
received press events for the modifier keys leading up to the
shortcut (if modifier press/release events have been enabled in the
kitty keyboard protocol - _Report all keys as escape codes_).
Closes#2257
Without this, the input handling code won't understand the key/mouse
event was consumed (i.e. triggered a shortcut), and will continue
processing normally (e.g. sending event to the client application).
Before this patch, foot used xrgb surfaces for all fully opaque
surfaces, and only used argb surfaces for the main window when the
user enabled translucency.
However, several compositors have damage-like issues when we switch
between opaque and non-opaque surfaces (for example, when switching
color theme, or when toggling fullscreen).
Since the performance benefit of using non-alpha aware surfaces are
likely minor (if there's any measurable performance difference at
all!), lets workaround these compositor issues by always using argb
surfaces.
