This was a bit of a PITA to run down; the essence of the problem
was that the shaper was returning an x_advance of 0 for U+3000,
which caused wezterm's shaping layer to elide that glyph.
I eventually tracked down the x_advance to be the result of
scaling by an x_scale of 0, which in turn is the result of
harfbuzz not knowing the font size.
The critical portion of this diff is the line that advises
harfbuzz that the font has changed after we've applied the
font size.
The rest is just stuff to make it easier to debug and verify.
This:
```
printf "x\u3000x."
```
Now correctly renders on screen as "x x".
fixes: #1161
Changing surface configuration flags *to* default would never be applied.
This was uncovered when implementing increment step resize: it would stop
working after *one* maximization.
The wl_keyboard definition does not define that the incoming fd is always at seek position 0.
In fact, the spec says the fd "can be memory-mapped" and that's it.
And e.g. smithay client-toolkit uses mmap, but we don't :/
Use pread() to read from zero.
This commit introduces a mechanism for specifying resize increments
for a window, and then arranges for the termwindow to set those
to match the current font cell metrics.
This should help to avoid cases where there is excess padding pixels
resulting from the window being slightly larger than computed number
of cells and the font metrics.
Fast-clicking users generally expect to be able to rapidly do regular selections
or otherwise cancel double/triple/quad clicks, so significant mouse movement should end the streak.
Allowing tiny pixel movements to account for touchpads is necessary.
Fortunately, the position here is already in character grid cells, which provides enough margin for this.
Other code editors like gedit also seem to do this based on the character grid.
It appears as though kakoune hides the terminal cursor and renders
its own version of the cursor.
The hidden state was being picked up by the copymode overlay,
making it awkward to use.
This commit forces the cursor to be visible (and a block) when
copy mode is active.
closes: #1113
- If possible use fontconfig to obtain character coverage instead of
going through all glyphs using freetype.
- `FT_Get_First_Char` typically returns ranges of continuous glyphs itself
and it is far cheaper (I measured a speedup of about 7 times while
catting a large file with lots of funny unicode) to add a range to the
glyph coverage instead of adding each glyph individually.
- Permit adding a range to a RangeSet without performing checks to speed
up things even further.
@H-M-H noticed and suggested this; rather than spawning a thread
for potentially every cluster of graphemes that are being displayed
before we've located a font, constrain things to a single thread
so that we don't burn CPU trying to process the same results
in an excessive number of threads.
I think this is a hangover from the older logic to figure out
the initial sizing, and I suspect that it is what is causing
refs: 1074
So this is a speculative change to see if it helps!
