All emoji graphemes are double-width. Foot doesn’t support non-latin
scripts. Ergo, this should result in the Right Thing, even though
we’re not doing it the Right Way.
Note that we’re now breaking cursor synchronization with nearly all
applications.
But the way I see it, the applications need to be
updated.
We’re mainly interested in seeing that we don’t leak memory, or double
free heap allocated data.
Valgrind and/or gcc/clang sanitizers are best at this, hence the very
few asserts in the test itself.
Instead of keeping removed/replaced key bindings in the key binding
array (marked as ‘unused’), remove them, by compacting the array.
The invariant is thus that there should be *no* entries in the key
binding list with the `BIND_ACTION_NONE` for action.
Add code to debug builds that verifies this, plus a unit test.
Closes#614
These extensions are used by tmux and neovim, in order to make use
of 24-bit colors without facing the problems that plague the `RGB`
capability.
This should allow 24-bit colors to work "out of the box" in tmux,
without the usual workaround of adding:
set-option -ga terminal-overrides ",foot*:Tc"
...to ~/.tmux.conf.
See also:
* 18fe2e8dfa (commitcomment-31373962)
* f83c25942d/runtime/doc/term.txt (L123-L139)
* b1a8c0fe02/CHANGES (L988-L989)Closes#615
This means that logging will be completely disabled until log_init()
has been called, which is useful to prevent log spam when running
UNITTEST{} blocks in debug builds.
Note that this doesn't change the default log level at runtime, which
was already being set to LOG_CLASS_INFO in main.c and client.c.
The new log level is also exposed to the command-line interface as
`--log-level=none`, which allows disabling logging entirely.
* Set win->configure.csd_mode, not win->csd_mode. Otherwise our
‘configure’ handler will swap out the CSD_YES we set, for
CSD_UNKNOWN(?), resulting in no CSDs at all.
* Don’t instantiate the CSDs in wayl_win_init(), let the ‘configure’
event handler do that. Just like it does when we have a decoration
manager emitting decoration configure events.
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.
