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
Previously, C0::VT was implemented as a simple 'cursor down'. I.e. it
would behave as LF **until** it reached the bottom of the screen,
where instead of scrolling, it became a no-op.
See https://vt100.net/docs/vt102-ug/chapter5.html
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.
We used to auto-resize images to always be a multiple of 6.
This is incorrect. The client may, for example, have specified a size
to align the image to a cell boundary, which may not be a multiple of
6.
Furthermore, in e.g. Jexer, which splits up an image into stripes,
that the next image would "overwrite" the previous one. Since the next
image was started on a cell row that the previous image had overflowed
into.
Since we don't have the original palette index in already rendered
cells, we compare the color *value*. If it matches, we assume this was
the color index used, and updates the cell's color.
Note that for performance reasons, we only update the current
grid. This is of course wrong, strictly speaking.
However, it is expected that _Set Color_ is used by full-screen
applications using the alternate grid.
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.
When making sure we don't scroll past the scrollback history, and the
current offset was exactly at the wrap around, the new view port was
set to offset+1, which in this particular case meant outside the valid
row numbers.
