This is primarily for macos where the default freetype
installation is unable to render color emoji, but should also
help make things more consistent across the various platforms.
It's a little bit awkward on linux because the font-loader crate
pulls in the now-conflicting servo-font* crates. I've disabled
font-loader on linux systems; it's just calling fontconfig under
the covers anyway.
We were incorrectly treating it as \r\n, but it should only have
been moving vertically.
This fixes the positioning of the cursor when using eg:
`dialog --yesno hello 0 0`
Without this change, the cursor would be way over to the left.
With this change, the cursor is correctly positioned inside
the "YES" box.
In the case where the screen was enlarged, we don't eagerly resize
the line vectors.
If a subsequent erase display occurred, we'd only erase to the old
size of the lines, rather than the new size, which could result
in a black square in the upper right corner of the display.
Repro scenario is:
* resize window larger than initial height
* `dialog --yesno hello 0 0`
The dialog background should fill the display.
This was responsible for eg: dialog rendering a black (or whatever
the default background color was) strip behind the text in an
invocation like:
`dialog --yesno hello 0 0`
Rather than render a default cell, render a blank cell using the
current pen.
The aim was to get to the bottom of why the coretext rendering seems
a bit off; the theory was that it was due to integer rounding somewhere,
but it seems that I still haven't gotten to the bottom of it here.
This was an off-by-one issue when using scroll margins just shorter
than the screen and when scrollback is enabled.
Added a unit test to verify the behavior.
I've had mixed results with esctest; the IRM and cursor save/restore
tests fail for me in terminal.app, iterm2 and xterm, and fail in the
same way on wezterm, so I'm not sure if I'm not running those tests
correctly. However, they did encourage the discovery of some other
real issues in the wezterm emulation.
These were showing up as unrecognized sequences on my mac, and I
wondered what they were. We now parse them and do nothing with
them, other than print out the parsed form :)
I wanted to see how much work remains to enable iterm2 image
display; one of the blockers was a limit in the size of the
buffer in the vte crate, which has been removed in my fork
of vte.
As part of testing our ability to absorb that data, I found
a couple of issues with applying the image cells to the display,
so this commit also takes care of that.
We still don't have code to connect the cell image data to the
opengl render layer.
Reduces the size of the full screen serialized size from 40k -> 13k.
Note that the `zlo` crate (which doesn't appear to have a repo
on github any longer; sources are only found in the crates.io
documentation source view), employes zigzag encoding of all integers
and floating point values and takes the size down to just under 10k.
A todo is to follow up on that and see if we could adopt the same
scheme in varbincode.
The `directories` crate unconditionally and eagerly tries to spawn
`xdg-user-dir` for all possible directories that it might be asked
about. This is relatively expensive and undesirable.
Shift to the `dirs` crate instead, which doesn't seem to need
to run `xdg-user-dir` at all.
Maintain these probed dirs as singletons via lazy_static.
