When the foot window is closed, and we need to terminate the client application,
do this in an asynchronous fashion:
* Don’t do a blocking call to waitpid(), instead, rely on the reaper callback
* Use a timer FD to implement the timeout before sending SIGKILL (instead of
using SIGALRM).
* Send SIGTERM immediately (we used to *just* close the PTY, and then wait 2
seconds before sending SIGTERM).
* Raise the timeout from 2 seconds to 60
Full shutdown now depends on *two* asynchronous tasks - unmapping the window,
and waiting for the client application to terminate.
Only when *both* of these have completed do we proceed and call term_destroy(),
and the user provided shutdown callback.
This breaks out the scrollback erasing logic for \E[3J from csi.c, and
moves it to the new function term_erase_scrollback(), and changes the
logic to calculate the start and end row (absolute) numbers of the
scrollback, and only iterate those, instead of iterating *all* rows,
filtering out those that are on-screen.
It also adds an intersection range check of the selection range, and
cancels the selection if it touches any of the deleted scrollback
rows.
This fixes a crash when trying to render the next frame, since the
selection now references rows that have been freed.
Closes#633
Up until now, *all* buffers have been tracked in a single, global
buffer list. We've used 'cookies' to separate buffers from different
contexts (so that shm_get_buffer() doesn't try to re-use e.g. a
search-box buffer for the main grid).
This patch refactors this, and completely removes the global
list.
Instead of cookies, we now use 'chains'. A chain tracks both the
properties to apply to newly created buffers (scrollable, number of
pixman instances to instantiate etc), as well as the instantiated
buffers themselves.
This means there's strictly speaking not much use for shm_fini()
anymore, since its up to the chain owner to call shm_chain_free(),
which will also purge all buffers.
However, since purging a buffer may be deferred, if the buffer is
owned by the compositor at the time of the call to shm_purge() or
shm_chain_free(), we still keep a global 'deferred' list, on to which
deferred buffers are pushed. shm_fini() iterates this list and
destroys the buffers _even_ if they are still owned by the
compositor. This only happens at program termination, and not when
destroying a terminal instance. I.e. closing a window in a “foot
--server” does *not* trigger this.
Each terminal instatiates a number of chains, and these chains are
destroyed when the terminal instance is destroyed. Note that some
buffers may be put on the deferred list, as mentioned above.
This patch adds a `confined` flag to each cell to track if the last
rendered glyph bled into it's right neighbor. To keep things simple,
bleeding into any other neighbor cell than the immediate right one is
not allowed. This should cover most use cases.
Before rendering a row we now do a prepass and mark all cells unclean
that are affected by a bleeding neighbor. If there are consecutive
bleeding cells, the whole group must be re-rendered even if only a
single cell has changed.
The patch also deprecates both old overflowing glyph options
*allow-overflowing-double-width-glyphs* and *pua-double-width* in favor
of a single new one named *overflowing-glyphs*.
There has been some confusion whether enabling DECSDM (private mode
80) enables or disables sixel scrolling.
Foot currently enables scrolling when DECSDM is set, and this patch
changes this, such that setting DECSDM now *disables* scrolling.
The confusion is apparently due to a documentation error in the VT340
manual, as described in
https://github.com/dankamongmen/notcurses/issues/1782#issuecomment-863603641.
And that makes sense, in a way: the SDM in DECSDM stands for Sixel
Display Mode. I.e. it stands to reason that enabling that disables
scrolling.
Anyway, this lead to https://github.com/hackerb9/lsix/issues/41, where
it was eventually proven (by testing on a real VT340), that foot, and
a large number of other terminals (including XTerm) has it wrong:
https://github.com/hackerb9/lsix/issues/41#issuecomment-873269599.
Removing overlaping and duplicated URLs is done by running two nested
loops, that both iterate the same URL list.
When a duplicate is found, one of the URLs is destroyed and removed
from the list.
Deleting and removing an item *is* safe, but only as long as _no
other_ iterator has references to it.
In this case, if we remove an item from e.g. the inner iterator, we’ll
crash if the outer iterator’s *next* item is the item being removed.
Closes#627
The previous implementation stored compose chains in a dynamically
allocated array. Adding a chain was easy: resize the array and append
the new chain at the end. Looking up a compose chain given a compose
chain key/index was also easy: just index into the array.
However, searching for a pre-existing chain given a codepoint sequence
was very slow. Since the array wasn’t sorted, we typically had to scan
through the entire array, just to realize that there is no
pre-existing chain, and that we need to add a new one.
Since this happens for *each* codepoint in a grapheme cluster, things
quickly became really slow.
Things were ok:ish as long as the compose chain struct was small, as
that made it possible to hold all the chains in the cache. Once the
number of chains reached a certain point, or when we were forced to
bump maximum number of allowed codepoints in a chain, we started
thrashing the cache and things got much much worse.
So what can we do?
We can’t sort the array, because
a) that would invalidate all existing chain keys in the grid (and
iterating the entire scrollback and updating compose keys is *not* an
option).
b) inserting a chain becomes slow as we need to first find _where_ to
insert it, and then memmove() the rest of the array.
This patch uses a binary search tree to store the chains instead of a
simple array.
The tree is sorted on a “key”, which is the XOR of all codepoints,
truncated to the CELL_COMB_CHARS_HI-CELL_COMB_CHARS_LO range.
The grid now stores CELL_COMB_CHARS_LO+key, instead of
CELL_COMB_CHARS_LO+index.
Since the key is truncated, collisions may occur. This is handled by
incrementing the key by 1.
Lookup is of course slower than before, O(log n) instead of
O(1).
Insertion is slightly slower as well: technically it’s O(log n)
instead of O(1). However, we also need to take into account the
re-allocating the array will occasionally force a full copy of the
array when it cannot simply be growed.
But finding a pre-existing chain is now *much* faster: O(log n)
instead of O(n). In most cases, the first lookup will either
succeed (return a true match), or fail (return NULL). However, since
key collisions are possible, it may also return false matches. This
means we need to verify the contents of the chain before deciding to
use it instead of inserting a new chain. But remember that this
comparison was being done for each and every chain in the previous
implementation.
With lookups being much faster, and in particular, no longer requiring
us to check the chain contents for every singlec chain, we can now use
a dynamically allocated ‘chars’ array in the chain. This was
previously a hardcoded array of 10 chars.
Using a dynamic allocated array means looking in the array is slower,
since we now need two loads: one to load the pointer, and a second to
load _from_ the pointer.
As a result, the base size of a compose chain (i.e. an “empty” chain)
has now been reduced from 48 bytes to 32. A chain with two codepoints
is 40 bytes. This means we have up to 4 codepoints while still using
less, or the same amount, of memory as before.
Furthermore, the Unicode random test (i.e. write random “unicode”
chars) is now **faster** than current master (i.e. before text-shaping
support was added), **with** test-shaping enabled. With text-shaping
disabled, we’re _even_ faster.
Before the grapheme cluster segmentation work, we limited the number
of combining characters to base+5. I.e. 6 in total.
For a while now, we’ve had it bumped all the way up to 20. This was
the reason the unicode-random benchmark ran so much slower (i.e. cache
contention).
Looking at emoji’s, there are a couple that need 6 code points,
and *three* that needs 7.
Now, with the limit at 7 chars, and the new ‘width’ member, the
composed struct is 8 bytes larger than before.
Using the frame callback works most of the time, but e.g. Sway doesn’t
call it while the window is hidden, and thus prevents us from updating
the title in e.g. stacked views.
This patch uses a timer FD instead. We store a timestamp from when the
title was last updated. When the application wants to update the
title, we first check if we already have a timer running, and if so,
does nothing.
If no timer is running, check the timestamp. If enough time has
passed, update the title immediately.
If not, instantiate a timer and wait for it to trigger.
Set the minimum time between two updates to ~8ms (twice per frame, for
a 60Hz output, and ~once per frame on a 120Hz output).
Closes#591
This commit also renames the term_set_single_shift_ascii_printer()
function to term_single_shift(), since the former is overly verbose
and not really even accurate.
These sequences are supposed to affect the next printable ASCII
character and then reset to the previous character set, but before
this commit they were behaving like locking shifts.
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.
We only needed term->font_scale to be able to detect scaling factor
changes (term->font_scale != term->scale).
But, we already have the old scaling factor in all places where
term_font_dpi_changed() is called, so let’s pass the old scaling
factor as an argument instead.
get_font_scale() was used to get the new scaling factor when loading
fonts. This was then compared to the last seen font scaling factor. If
there was no difference, the fonts were not reloaded.
The problem was, the initial term->scale was set differently. This
sometimes led to term->scale=2, while get_font_scale() return 1. That
meant, fonts were initially scaled by 2 (when dpi-aware=no). Later,
when mapped on an output (and thus term->scale being set to 1), the
fonts weren’t reloaded with the correct scaling factor since the
cached term->font_scale value was already 1.
Since term->scale always reflects the *new* scaling factor when
term_font_dpi_changed() is called, use that directly, and remove
get_font_scale().
Also rename the following functions:
* font_should_size_by_dpi() -> font_size_by_dpi_for_scale()
* font_size_by_dpi() -> font_sized_by_dpi()
* font_size_by_scale() -> font_sized_by_scale()
Instead of using CELL_SPACER for *all* cells that previously used
CELL_MULT_COL_SPACER, include the remaining number of spacers
following, and including, itself. This is encoded by adding to the
CELL_SPACER value.
So, a double width character will now store the character itself in
the first cell (just like before), and CELL_SPACER+1 in the second
cell.
A three-cell character would store the character itself, then
CELL_SPACER+2, and finally CELL_SPACER+1.
In other words, the last spacer is always CELL_SPACER+1.
CELL_SPACER+0 is used when padding at the right margin. I.e. when
writing e.g. a double width character in the last column, we insert a
CELL_SPACER+0 pad character, and then write the double width character
in the first column on the next row.
* Rename cursor.style value ‘bar’ to ‘beam’. ‘bar’ remains recognized,
but should eventually be deprecated and then removed.
* Add ‘cursor.beam-thickness’ option, a pt-or-px value specifying the
thickness of the beam cursor. Defaults to 1.5pt.
* Rename (and export) pt_or_px_as_pixels() to
term_pt_or_px_as_pixels()
* Change term_pt_or_px_as_pixels() to round point values instead of
truncating them.
This ensures different seat’s don’t step on each others IME pre-edit
state.
It also removes most dependencies on having a valid term pointer for
many IME operations.
We’re still not all the way, since we support disabling IME with a
private mode, which is per terminal, not seat.
Thus, we still require the seat to have keyboard focus on one of our
windows.
Closes#324. But note that *rendering* of multiple seat’s IME pre-edit
strings is still broken.
When the user has set a custom line-height, we now adjust it when
increasing/decreasing (“zooming”) the font size at run-time.
Previously, the line-height was fixed at the size specified in
foot.ini.
term_print() is called whenever the client application “prints”
something to the grid. It is called for both ASCII and UTF-8
characters, and needs to handle sixels, insert mode and ASCII
vs. graphical charsets.
Since it’s on the hot path, this becomes unnecessarily slow.
This patch adds a “fast” version of term_print(), tailored for the
common case: ASCII characters in non-insert mode, without any sixels
and non-graphical charsets.
A new function, term_update_ascii_printer(), has been added, and must
be called whenever:
* The currently selected charset *index* changes
* The currently selected charset changes (from ASCII to graphical, or
vice verse)
* Sixels are added to the grid
* Sixels are removed from the grid
* Insert mode is enabled/disabled
When P2=1, empty pixels are transparent.
This patch also changes the behavior of P2=0|2, from setting empty
pixels to the default background color, to instead use the *current*
background color.
To implement this, a couple of changes are needed:
* Sixel pixels always use alpha=1.0, except for *empty* cells when
P2=1 (i.e. transparent pixels).
* The renderer draws sixels with the OVER operator, instead of the SRC
operator.
* The renderer *must* now render the cells beneath the sixel. As an
optimization, this is only done for sixels where P2=1. I.e. for
fully opaque sixels, there’s no need to render the cells beneath.
The sixel renderer isn’t yet hooked into the multi-threaded
renderer. This means *rows* (not just the cells) beneath
maybe-transparent sixels are rendered single-threaded.
Closes#391.
All-empty pixels rows in the last sixel row should not be included in
the final sixel image.
This allows applications to emit sixels whose height is not a multiple
of 6, and is how XTerm works.
This is done by tracking the largest row number that contains
non-empty pixels.
In unhook, when emitting the image, the image height is adjusted based
on this value.
By storing the current row’s byte offset into the backing image in the
terminal struct.
This replaces the ‘imul’ with a load, which can potentially be
slow. But, this data should already be in the cache.
Foot has, up until now, used a fixed image size when the application
used DECGRA (Raster Attributes) to “configure” the image size.
This was based on a misunderstanding, that this was how you emitted
sixels where the height was *not* a multiple of 6.
This isn’t the case. The VT340 documentation is actually pretty clear
about this:
Ph and Pv do not limit the size of the image defined by the sixel
data. However, Ph and Pv let you omit background sixel data from the
image definition and still have a color background. They also
provide a concise way for the application or terminal to encode the
size of an image.
This is also how XTerm behaves. Test image:
\EPq
"1;1;1;1
#0;2;0;0;0#1;2;100;100;0#2;2;0;100;0
#1~~@@vv@@~~@@~~$
#2??}}GG}}??}}??-
#1!14@
\E\
This uses DECGRA to set the image size to 1x1. The sixel however
is *not* clipped to 1x1, but is resized to 14x12
When enabled (the default), sixels behave much like normal output; the
start where the cursor is, and the cursor moves with the
sixel. I.e. after emitting a sixel the cursor is left after the image;
either to the right, if private mode 8452 is enabled, or otherwise on
the next line. Terminal content is scrolled up if the sixel is larger
than the screen.
When disabled, sixels *always* start at (0,0), the cursor never moves,
and the terminal content never scrolls.
In other words, the ‘disabled’ mode is a much simpler mode.
All we need to do to support both modes is re-write the sixel-emitting
loop to:
* break early if we’re “out of rows”, i.e. we’ve reached the bottom of
the screen.
* not linefeed, or move the cursor when scrolling is disabled
This patch also fixes a bug in the (new) implementation of private
mode 8452.
When emitting a sixel, we may break it up into smaller pieces, to
ensure a single sixel (as tracked internally) does not cross the
scrollback wrap-around.
The code that checked if we should do a linefeed or not, would skip
the linefeed on the last row of *each* such sixel piece. The correct
thing to do is to skip it only on the last row of the *last* piece.
I chose not to fix this bug in a separate patch since doing so would
have meant re-writing it again when implementing private mode 80.
Previously, we automatically exited URL mode whenever we received data
on the PTY. This was done since we don’t know _what_ has changed on
the screen, and we don’t want to display misleading jump labels.
However, this becomes a problem in curses-like applications that
periodically updates part of the screen. For example, a statusbar with
a clock.
This patch changes this behavior; instead of cancelling URL mode when
receiving PTY data, we snapshot the grid when entering URL mode.
When *rendering*, we use the snapshot:ed grid, while PTY updates
modify the “real” grid.
Snapshot:ing the grid means taking a full/deep copy of the current
grid, including sixel images etc.
Finally, it isn’t necessary to “damage” the entire view
when *entering* URL mode, since we’re at that point the renderer is in
sync with the grid. But we *do* need to damage the entire view when
exiting URL mode, since the grid changes on the “real” grid hasn’t
been tracked by the renderer.
When disabled (the default), the cursor is positioned on a new line
after emitting a sixel image.
When enabled, the cursor is positioned to the right of the sixel
image.
Closes#363
When enabled (the default), sixels use private color registers. That
is, the color palette from the last sixel is *not* re-used.
When disabled, sixels share (i.e. re-use) the same color palette.
Closes#362
This patch adds a new configuration option,
‘osc8-underline=url-mode|always’.
When set to ‘url-mode’, OSC-8 URLs are only
highlighted (i.e. underlined) in url-mode, just like auto-detected
URLs.
When set to ‘always’, they are always underlined, regardless of mode,
and regardless of their other attributes.
This is implemented by tagging collected URLs with a boolean,
instructing urls_render() and urls_reset() whether they should update
the cells’ ‘url’ attribute or not.
The OSC-8 collecter sets this based on the value of ‘osc8-underline’.
Finally, when closing an OSC-8 URL, the cells are immediately tagged
with the ‘url’ attribute if ‘osc8-underline’ is set to ‘always’.
By default, the URL isn’t shown on the jump-label. For auto-detect
URLs, doing so is virtually always useless, as the URL is already
visible in the grid.
For OSC-8 URLs however, the URL is often _not_ visible in the
grid. Many times, seeing the URL is still not needed (if you’re doing
‘ls --hyperlink’, you already know what the URIs are).
But it is still useful to have a way to show the URLs.
This patch adds a new key binding action that can be used in url-mode
to toggle the URL on and off in the jump label.
It is bound to ctrl+t by default.
In case an URL is split up into multiple parts, those parts are now
treated as a single URL when it comes to key assignment.
Only the *first* URL part is actually assigned a key combo. The other
parts are ignored.
We still highlight them, but for all other purposes they are ignored.
These functions update the OSC-8 URI state in the terminal.
term_osc8_open() tracks the beginning of an URL, by storing the start
coordinate (i.e. the current cursor location), along with the URL
itself.
Note that term_osc8_open() may not be called with an empty URL. This
is important to notice, since the way OSC-8 works, applications close
an URL by “opening” a new, empty one:
\E]8;;https://foo.bar\e\\this is an OSC-8 URL\E]8;;\e\\
It is up to the caller to check for this, and call term_osc8_close()
instead of term_osc8_open() when the URL is empty.
However, it is *also* valid to switch directly from one URL to
another:
\E]8;;http://123\e\\First URL\E]8;;http//456\e\\Second URL\E]8;;\e\\
This use-case *is* handled by term_osc8_open().
term_osc8_close() uses the information from term_osc8_open() to add
per-row URL data (using the new ‘extra’ row data).
