When printing a multi-column character, write CELL_MULT_COL_SPACER
instead of '0' to both padding cells (when character doesn't fit at
the end of the line), and to the cells following the actual character.
When printing a multi-column character at the end of the line, and it
doesn't fit, we currently insert a forced line-wrap. This means the
last character(s) on the previous line will be empty, followed by a
multi-column character in the first cell on the next line.
Without special code to handle this, the selection text extraction
code will insert a hard newline, since this is normally the correct
thing to do.
Add a TODO, to consider writing a special place holder value to these
padding cells.
While this might seem like it would slow down things, it should in
fact help the compiler optimize: the "normal" code path, that prints
regular ASCII characters, always call term_print() with width == 1.
LF should always clear LCF. Previously, it was done implicitly in
term_cursor_down(). I.e it was cleared as long as the cursor wasn't at
the bottom of the scrolling region
Instead of locking the queue for each dirty row we append, and
signaling a condition variable, just keep the lock while going through
the visible rows.
Release the lock once done.
Since we take the lock *before* posting the 'start' semaphore, all
workers will be waiting for the lock to be released.
Then, one at a time they'll get the lock and pick a row to
render. The queue will never get empty - when all rows have been
rendered, each worker will pick a 'frame done' "job" from the queue,
and break the rendering loop.
* xcursor always set for all pointers
* xcursor sometimes not updated when it should be
* mouse grabbed state wasn't per seat, but global (i.e. "does at least
one seat enable mouse grabbing")
* selection enabled state wasn't per seat
That is, only call term_kbd_focus_in() if we're the *first* seat
focusing that terminal, and only call term_kbd_focus_out() if we're
the *last* seat that focused it.
When resizing the font on-the-fly, we now do a complete
font-reload (this is basically what fcft_size_adjust() did anyway).
To get the correct size, we maintain the current size ourselves.
We get the initial size from the user-provided font pattern, by
converting the string to an FcPattern, and using FcPatternGet() to
retrieve both the FC_SIZE and FC_PIXEL_SIZE attributes. These
attributes are then removed from the pattern, and the pattern is
converted back to a string.
The terminal struct maintains a copy of the font sizes. These are
initially set to the sizes from the config.
When the user resizes the font, the terminal-local sizes are
adjusted. To ensure the primary and user-configured fallback fonts are
resizes equally much, convert any pixel sizes to point sizes at this
point.
When the font size is reset, we reload the font sizes from the
config (thus once again returning actual pixel-sizes, if that's what
the user has configured).
The logic that breaks out of sixel loops does not work for rows that
has already wrapped around.
Thus, we need to destroy sixels that are about to be scrolled
out *before* we actually scroll.
Since this is the *only* time we destroy sixels (instead of
overwriting it), rename the sixel functions. And, since they now do a
very specific thing, they can be greatly simplified (and thus faster).
If changing the font size causes the cell size to decrease, either
horizontally or vertically (or both), then delete all sixels since the
grid space they allocated no longer is enough to hold the images.
Instead of completely erasing a sixel image when it is being
"overwritten" (text is printed somewhere within the image, or another
sixel image is emitted within the first image), split it up into up to
four pieces: 'above', 'below', 'to-the-left' and 'to-the-right'.
This is currently very un-optimized, but seems to produce correct
results.
A client can re-use the palette between images. Resetting the palette
breaks this.
Now we initialize the palette on demand, and resets it when the
palette size is changed (by the client).
Since foot is pretty aggressive about spawning the client early, it
was possible for a fast client to read a 0x0 terminal size. Not all
clients coped well.
Closes#20.
