Fixes#2099
This is another heuristic of sorts to make `window-padding-color=extend`
look better by default. If a fully covering glyph is used then we use
the fg color to extend rather than the background.
This doesn't account for fonts that may do this for whatever codepoints,
but I think that's a special scenario that we should just recommend
disabling this feature.
With a minimum contrast set, the colored glyphs that Powerline uses
would sometimes be set to white or black while the surrounding background
colors remain unchanged, breaking up contiguous colors on segments of
the Powerline.
This no longer happens with this patch as Powerline glyphs are now
special-cased and exempt from the minimum contrast adjustment.
There are scenarios where this configuration looks bad. This commit
introduces some heuristics to prevent it. Here are the heuristics:
* Extension is always enabled on alt screen.
* Extension is disabled if a row contains any default bg color. The
thinking is that in this scenario, using the default bg color looks
just fine.
* Extension is disabled if a row is marked as a prompt (using semantic
prompt sequences). The thinking here is that prompts often contain
perfect fit glyphs such as Powerline glyphs and those look bad when
extended.
This introduces some CPU cost to the extension feature but it should be
minimal and respects dirty tracking. This is unfortunate but the feature
makes many terminal scenarios look much better and the performance cost
is minimal so I believe it is worth it.
Further heuristics are likely warranted but this should be a good
starting set.
Fixes#1784
This was just a misunderstanding of the "spec." When both a y offset
into the image is specified and a height, the image should be stretched.
I mistakingly thought that the image should be offset (even with this
misunderstanding there was a data corruption bug).
This resolves the issue and output matches Kitty.
When hot reloading config with a new font, shaper cache data needs to be
invalidated and the font grid needs to be rebuilt. This change just
makes that happen on all config reloads since it's a rare action so it's
not a performance concern.
Fixes#1416
At a high level, the issue is that when mouse capture is enabled (i.e. in
neovim), "shift" escapes the capture. So "cmd+shift" is equal to "cmd"
which doesn't get sent to the TUI program and so on. For link
highlighting which now requires "cmd" (super) is held, we were sending
"cmd+shift" to the renderer so we weren't checking for links.
So the core of this commit is respecting this scenario and stripping the
shift modifier.
This commit also found that when the mouse wasn't over a link, we were
always checking and highlighting links on line one of the visible
screen. This bug is fixed and should also result in a very slight
performance improvement on rendering in all cases.
Up to this point, every font I've experienced with ligatures has
replaced the codepoints that were replaced for combining with a space.
For example, if a font has a ligature for "!=" to turn it into a glyph,
it'd shape to `[not equal glyph, space]`, so it'd still take up two
cells, allowing us to style both.
Monaspace, however, does not do this. It turns "!=" into `[not equal
glyph]` so styles like backgrounds, underlines, etc. were not extending.
This commit detects multi-cell glyphs and inserts synthetic blank cells
so that styling returns. I decided to do this via synthetic blank cells
instead of introducing a `cell_width` to the shaper result because this
simplifies the renderers to assume each shaper cell is one cell. We can
change this later if we need to.
Annoyingly, this does make the shaper slightly slower for EVERYONE to
accomodate one known font that behaves this way. I haven't benchmarked
it but my belief is that the performance impact will be negligible
because to figure out cell width we're only accessing subsequent cells
so they're likely to be in the CPU cache and also 99% of cells are going
to be width 1.
