* First step towards implementing #4226.
* Added InputSelector config options.
* Format + fix to prepare for PR to resolve#4226.
* Accept suggestion about pop().
* Fix typo.
* Tried fixing stuff from the feedback.
* Fixed typo.
* Fixed small mistake in docs.
* Small fix for label computation.
* Allow uppercase alphabet + add fuzzy_description.
* Minor cleanup.
* Use more standard alphabet (without j/k).
* Fixed docs after previous commit.
* Added key assignments to docs.
* Apply suggestions from code review (2 remaining)
* Updated arcording to feedback (added tests).
* Update docs (1 thing left to do)
* Added version details to the key table.
---------
Co-authored-by: Wez Furlong <wez@wezfurlong.org>
Previously we'd use the scaled-by-line-height-and-cell-width dimensions
for the text cursor, leading to oddly dimensioned block cursors when
`line_height` or `cell_width` were configured.
This commit captures the native cell dimensions into the RenderMetrics
which makes it feasible for the glyph and sprite rendering logic to
reason about it.
The cursor rendering now renders at the native size and position by
using a transform to scale and translate into the correct spot.
We could potentially use the same technique for eg: braille or
other non-drawing characters
(https://github.com/wez/wezterm/issues/1957) although that is more
complex than just this commit.
refs: https://github.com/wez/wezterm/issues/2882
Previously we'd return the Url string. Now we provide a Url
object that provides access to the various elements of the Url.
This will cause slightly breakage for folks that were treating
it as a string in their status event handlers, for example.
The docs have been updated to show how to run with both this
new Url object and also continue to run on older versions of
wezterm.
They now also show how to manually percent decode the url
for older versions of wezterm.
refs: https://github.com/wez/wezterm/discussions/4157
refs: https://github.com/wez/wezterm/issues/4000
Move the shortcode aliases out from the various emoji category
pages and into a new shortcode page.
Add variations, such as skin tones, to the different emoji
category pages.
This gets the matching time down below 110+ms to around 70ms
in release mode, which may not sound like a huge amount, but 100ms
is on the cusp of perceivable latency, so getting below that is
desirable.
When using the harfbuzz rasterizer with a bitmap glyph, the result
is a rasterized glyph that is pre-scaled to the cell dimensions.
We need to tell glyphcache that that has happened, otherwise it
will apply the same scale factor again.
Neither of these understand image protocols, and both are
an additional processing layer between the application and
wezterm.
This commit detects and wraps OSC sequences in tmux's passthru
sequence so that the data is passed on to wezterm rather than
elided from the data stream.
For image protocols in both tmux and conpty, work a little
smarter and explicitly move the cursor position to the same
location that wezterm would move it to. That prevents the
display from being as mangled by tmux/conpty due to a diverging
understanding of the cursor position.
The logic isn't perfect, and can result in the x-coordinate
being incorrect, and this won't work with the new --position
argument either in its current state, without adding a lot
of complexity to deal with scrolling and relative and absolute
positioning handling.
To facilitate that, a new termwiz Terminal trait method has
been added to probe the terminal name, version, cell and pixel
dimensions. It's not pretty.
refs: https://github.com/wez/wezterm/issues/3624
refs: https://github.com/wez/wezterm/issues/3716
Relocate the helper function to mux-server-impl and have both the GUI
and the mux server call it at the appropriate times.
Introduce default_mux_server_domain which is used instead of
default_domain in the mux server. This is to avoid recursive
cycles when starting up the mux; we don't want the default
domain to be a unix client that connects to our selves because
we'll try to connect to ourselves, then in act of handling that
spawn in the default domain and try to connect to ourselves and
repeat.
refs: https://github.com/wez/wezterm/issues/3907
Previously the same emoji was able to appear multiple times in the
CharSelect modal for emoji input, because one emoji might have multiple
aliases. In fact, often the aliases have similar names, making it
especially likely that a fuzzy match matches multiple aliases at the
same time.
The same Unicode char may even match multiple times both as
Character::Unicode as well as a Character::Emoji.
To make the deduplication easy, store the results in a hash map instead
of a vector. We use the glyph as the key of the map to get free
deduplication.
Only update the mapped value, if a duplicate entry would improve the
score.
Performance-wise this is pretty much identical to the previous state.
We do see minor performance regression for very large n - granted, this
is expected as we do more work - but the use of the HashMap covers up
for a large part of it.
If the user types more than 3 characters, the performance is absolutely
identical. For less than 3 characters, the performance was unacceptable
anyway (700 ms before this patch, 800 ms after this patch on my system).
Here is a side-by-side comparison for a user iteratively typing the
query "no-evil":
# Before After
1 718.361276ms 837.612275ms
2 719.532450ms 816.348394ms
3 349.625101ms 369.726458ms
4 356.349671ms 354.367768ms
5 363.862194ms 361.985546ms
6 372.339582ms 370.022932ms
7 381.123785ms 378.349672ms
In fact, for small n, the hash map seems to perform even slightly better
than the vector.
For large n we need to optimize the performance anyway, as both 700ms
and 800ms are unacceptable.
Thus, this is worth it for the benefit of Unicode symbol deduplication.
I believe that this was obsoleted long ago by the ThreadedWriter
logic that is present in the terminal implementation so we no
longer need to limit the write chunk size.
refs: #3683
Arrow keys have ENHANCED_KEY set in the mods, and shifted keys had
positional mods in things like quickselect.
Strip them out.
I think I got all the cases, but it's possible that one slipped
through.
refs: https://github.com/wez/wezterm/issues/3617
If you haven't registered an augment-command-palette event,
you'd see:
```
16:29:02.641 WARN wezterm_gui::termwindow::palette >
augment-command-palette: error converting Lua nil to Rust Type (Cannot
convert `Null` to `Vec`)
```
refs: https://github.com/wez/wezterm/issues/3595
When trying to display a 4k image there is a high chance that
we'll run out of texture space and then render with no images
displayed.
This commit changes the binary yes/no allow-images into a a series
of attempts: display at natural size, scale down by 2, 4, then 8,
then give up on images.
While looking at this, I noticed that we had a TOCTOU in the blob lease
stuff in the case where we might very quickly try the handle the same
image in succession, and end up deleting a file out from under a live
lease.
I've put in place a simple bandaid for that, but it's probably worth
revisiting the concurrency model for that.
This is a regression caused by recent work such as 27fbff4ae1
This config wouldn't set the background color to red because we'd never
consider the frame to be loaded:
```lua
local wezterm = require 'wezterm'
local config = wezterm.config_builder()
config.background = {
{ source = { Color = '#FF0000' }, width = '100%', height = '100%' },
}
return config
```
Avoid a "flash" of a single black but likely overly stretched and
awkwardly interpolated frame while we wait for big/animated/complex
images to load and decode.
For corrupt images, or images with an incorrect or typo'd filename in
the config, this prevents us from punting and just showing a transparent
background instead of something reasonable.
