XTerm seems to ignore these when in UTF-8 mode. Since we _only_
support UTF-8, we don't need to recognize these control characters at
all.
However, it may be good to have them here for reference. So add them,
but commented out, along with their corresponding 7-bit
versions (which we _do_ recognize and implement).
When we insert an auto-newline, we must make sure we don't try to move
outside the terminal window.
This can for example happen when a scrolling region have been
configured, and the cursor is **outside** the scrolling
region (i.e. it's in the bottom margin).
Having them as error messages was nice when we where still missing
lots of sequences.
Now we don't anymore, and these just spam stdout as well as syslog
when e.g. cat:ing binary data.
In most states, most 8-bit values are no-ops. This is already handled;
action() recognizes ACTION_NONE as a no-op. Thus, all we need to do is
remove the assertion.
* It takes a parameter, that indicates the number of tab stops to move
through
* Use the tab stops defined in the tab stops list, not hard coded mod
8 columns.
There were actually two bugs here:
* When checking for a tab stop, make sure the new tab stop is at a
different column. Otherwise you can't tab away from a tab stop.
* When there aren't any tab stops configured, or when we're already
beyond the last tab stop, then tab to the last column (at least I
think that's what we're supposed to do).
The CLEAR action is so common, that explicitly clearing the entire
params array, which is kind of big, is too slow.
Clear it lazily instead. Meaning, we only set 'idx' (count) to 0 in
CLEAR. Then whenever we parse a parameter, clear the value and sub
parameters.
The 'attributes' struct is now 8 bytes and naturally packed (used to
be 9 bytes, artificially packed).
'cell' struct is now 12 bytes, naturally packed (used to be 13 bytes,
artificially packed).
Furthermore, the glyph is stored as a wchar instead of a char*. This
makes it easier (faster) to do glyph lookup when rendering.
Fonts are now loaded with FT_LOAD_COLOR and we recognize and support
the FT_PIXEL_MODE_BGRA pixel mode.
This is mapped to a CAIRO_FORMAT_ARGB32 surface, that is blitted
as-is (instead of used as a mask like we do for gray and mono glyphs).
Furthermore, since many emojis are double-width, we add initial
support for double-width glyphs.
These are assumed to always be utf8. When PRINT:ing an utf8 character,
we check its width, and add empty "spacer" cells after the cell with
the multi-column glyph.
When rendering, we render the columns in each row backwards. This
ensures the spacer cells get cleared *before* we render the glyph (so
that we don't end up erasing part of the glyph).
Finally, emoji fonts are usually bitmap fonts with *large*
glyphs. These aren't automatically scaled down. I.e. even if we
request a glyph of 13 pixels, we might end up getting a 100px glyph.
To handle this, fontconfig must be configured to scale bitmap
fonts. When it is, we can look at the 'scalable' and 'pixelsizefixup'
properties, and use these to scale the rendered glyph.
Replace with generic error log messages that simply says the
ESC/CSI/OSC sequence is unhandled. This can mean either invalid or
unimplemented, depending on the context.
