This got a bit broken by the fix for https://github.com/wez/wezterm/issues/714
since we can be handed a range of logical line fragments, we should
test each of them to find our matching result.
Also, improve the logic for constraining the length when looking
backwards.
This commit introduces the knowledge about whether a font is
scalable or was using bitmap strikes (eg: color emoji bitmaps).
Then that information is used to help figure out whether and
how to scale a glyph.
refs: https://github.com/wez/wezterm/issues/685
Since the original code was written, Rust grew and stabilized
an interface for specifying argv0 for the child process, so
we can remove the fragile `-l` argument passing.
refs: https://github.com/wez/wezterm/issues/753
* Better function for undercurl
* Setting lower alpha
* underline alpha in line-frag
* make undercurl alpha background independent
* Improved Shader
* Old Rasterization
Co-authored-by: Roland Fredenhagen <git@modprog.de>
When the title, icon, OSC 7 and SetUserVars sequences are processed,
notify the embedding application.
The gui layer uses this to trigger a titlebar update.
refs: #647
Previously, we used `git describe --tags` to produce a version number
for non-released builds derived from the most recent tag + some info
such as the number of commits since that tag and then `g{HASH}`.
That always confuses people because the date portion at the front
looks old (it is typically the previous release) and the hash at
the end has that `g` in it.
This commit simplifies both the tag name used when making a release
and the computed version number take the date/time from the current
commit, and then append the hash. That way the version number always
corresponds to a commit.
This scheme doesn't help detect situations where the commit is
dirty, but I don't think the old one would have helped with that
either.
the binary search would falsely extend the end of the match
to the start of the subsequent match for the wrapped line case.
The resolution is to emit a coordinate for the newline that we
add to the haystack between the wrapped lines.
closes: https://github.com/wez/wezterm/issues/732
In the situation where we have a full screen terminal (eg: 500 cells
wide), but very little output (eg: only 10's of columns on the left are
NOT blank), we would previously spend a non-trivial amount of time
calculating fg/bg colors for the blanks that trailed the actual
clusters; the calculation for each row was:
O(trailing-blanks * full cell color compute cost)
which was around 30us per row. For large numbers of rows this could
add up to >10ms per frame.
This commit changes the logic to run in two phases:
* O(selection-width) with simple fg/bg color updates for the selection
range
* O(1) full cell color compute cost for the cursor if the cursor
is somehow in the trailing blank region and not already handled
by the earlier clustering logic.
With the sequence of recent commits, the frame time for the large
terminal case has been reduced from ~22ms to ~7ms, which is approx 3x
improvement.
refs: #740
This has the effect of reducing the memory and scroll cost
for lines that are shorter than the physical width of the
terminal matrix.
refs: https://github.com/wez/wezterm/issues/740
It looks like the mux search results include a trailing newline
in some cases, which means that a match can wrap onto a second
line.
If that line is shorter than the label length, we could panic.
This commit makes quickselect safer to use in this situation,
but the real fix is with the mux search code.
