Adds some plumbing to track the current mouse position and
extract the hyperlink from the cell that is being hovered over.
We render those cells with underline, possibly in a different color.
We don't yet do anything on click.
This felt a bit repeatey and it pre-dated the TerminalHost trait.
I'd like to remove it completely but there are some frustrating and
fiddly lifetime concerns with mutable TerminalHost reference so I'm
hiding it from the public interface and bridging it the answerback
stream into the host at the bottom of the advance_bytes method for
now.
This also improves perf. The issue was that the erase of the whole
line of the background may be observed by the X server when SHM is
enabled because we don't wait for the exposure/copy to the window
pixmap before updating the same row fractionally later.
Avoiding the unconditional erase and just painting the full cell
contents over means that there's no opportunity for a visible flash.
In addition, since we render the cells background individually, that
erase was not needed.
This should save us some work and take some load off the cpu.
This wasn't correctly handling double-width or ligatures. In addition,
don't respect the x_advance outside of a ligature run, as it can result
in slightly offset columns for example when `ls -l` shows `--` and that
sequence has a slightly less wide ligatured rendition.
```
echo -e '\e[4mu--nder\e[0m \e[21mdo--uble\e[0m \e[9mst--rike\e[0m'
```
We were panicking when rendering the || ligature, which is narrower
than we were expecting. There was also a weird looking assert
that was triggering if we got path the math overflow.
I wasn't pleased with how text was rendering on a colored background,
and after some research I discovered that I was neglecting to convert
from sRGB to a linear RGB colorspace, and that this was causing the
blending to have inaccurate results.
This diff pulls in the palette crate to handle the heavy lifting.
It doesn't appear to have any especially fast optimizations for this
though, which is a shame because the blending code I was using
previously was largely integer math with few branches. The colorspace
conversion has several floating point operations and branches that
are unavoidable :-/
We run a bit hotter on the CPU but the results are much more pleasing
to the eye.
This is most noticable with a cursive italic font. When we
were dividing the glyph into cell slices, we could leave off
a 2 pixel wide strip from the last of the sequence and this
looked nasty.
This diff also adjusts come calculations to use the width and
height from the current TextStyle. Whether this is more or
less correct remains to be seen :-p
This enables selecting an italic font when the cell is italic,
but has more power beyond just that simple property.
This runs a little hot on the CPU so there's probably some caching and
tweaking that can be done to make the evaluation a bit cheaper.
