Long OSC-8 URIs, that are split up over multiple rows, are handled by
emitting one URI range on each row the URL touches.
This was done by initializing a row index variable, and then
incrementing it each loop iteration.
This caused an out-of-bounds array access when the row index reached
the maximum number of scrollback lines.
The fix is simple: make sure the row index variable wraps around,
instead of incrementing without any bounds.
Closes#552
These are part of the "anywhere" state in Paul Flo Williams' VT parser
state diagram[1]. That means that they should be accepted *anywhere* in
a byte sequence, including in the middle of other sequences or even in
the middle of a multi-byte UTF-8 sequence. Adhering to this requirement
makes them incompatible with the use of UTF-8 as a universal encoding.
Not adhering to the aforementioned requirement by making a special case
for UTF-8 sequences may seem tempting, but it's much more at odds with
the relevant standards[2] than it appears on the surface. UTF-8 is not
an "8-bit code", at least not according to the parlance of ECMA-43, nor
does it map the C1 control range in a compatible way.
[1]: https://vt100.net/emu/dec_ansi_parser
[2]: ECMA-35, ECMA-43, ECMA-48
ayl_roundtrip() has the following code:
wl_display_roundtrip(wayl->display);
while (wl_display_prepare_read(wayl->display) != 0)
wl_display_dispatch_pending(wayl->display);
wayl_flush(wayl);
If the first wl_display_roundtrip() fails, for example because the
Wayland socket has been closed, we may get stuck in the while-loop.
This happens if the read queue isn’t empty, in which case
wl_display_prepare_read() will return -1 and we’ll continue trying to
dispatch the pending events forever, never succeeding since the socket
is gone.
Closes#542
Since we know the following:
* URI ranges are sorted
* URI coordinates are unique
* URI ranges don’t cross rows
We can optimize URI range reflowing by:
* Checking if the *first* URI range’s start coordinate is on the
current column. If so, keep a pointer to it.
* Use this pointer as source when instantiating the reflowed URI range
* If we already have a non-NULL range pointer, check its end
coordinate instead.
* If it matches, close the *last* URI range we inserted on the new
row, and free/remove the range from the old row.
* When line breaking, we only need to check if the *last* URI range is
unclosed.
This expects a hyphen, not underscore, in the option name:
err: config.c:892: /home/user/.config/foot/foot.ini:34: [bell]: command_focused: invalid key
echo -e '\e]8;;https://www.foo.bar\e\\https://www.foo\e]8;;\e\\.bar'
will produce an OSC-8 URL (https://www.foo) that is slightly shorter
than the auto-detected one (https://www.foo.bar).
This produces strange results in URL mode. For example, if
url.osc8-underline=always, the OSC8 underline will be removed when
url-mode is exited.
This patch changes the behavior so that auto-detected URLs that
overlap OSC-8 URLs are removed.
Note that OSC-8 URLs cannot overlap with each other, and that
auto-detected URLs also cannot overlap with each other.
Works in pretty much the same way as ‘beam-thickness’, except that the
default value is “the font’s underline thickness”.
This means, that when unset, the cursor underline thickness scales
with the font size.
But, when explicitly set, either to a point size value, or a pixel
size, it remains fixed at that size.
Closes#524
This fixes an issue where we, at least on FreeBSD, sometimes get stuck
in epoll_pwait() after the shell has exited.
It turned out to be because the SIGCHLD signal was delivered at the
same time FDs were made readable/writeable. I.e. epoll_pwait()
returned a non-zero value even though it should have been interrupted
by the SIGCHLD.
To avoid having to search the entire signal array *every time*
epoll_pwait() returns, add a flag that is set in the signal
handler. This tells the FDM to scan the signal array after returning
from epoll_pwait().
\e[21m was previously used to disable bold. That changed a while ago,
to align foot with the majority of other terminal emulators.
\e[22m now disables both bold and dim.
When this change was done, the user notifications were not updated,
meaning the ‘message’ part was always in bold. This was never the
intended behavior.
So that the value is clamped to the range [0, 0x7fffffff] and retains
the same value, regardless of whether it's interpreted as a signed or
unsigned integer.
Closes#522
It _may_ be acceptable in e.g. tiling WMs, where windows are seldom
resized interactively.
But in a stacking WM where the typical way of resizing windows is by
interactive resizes, this spams way too much.
