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.
There were a couple of layers of issue here:
* In the ImageDataType::decode method, we didn't detect and do something
reasonable when the decoded image had 0 frames, later leading to
a panic in glyphcache when trying to index frame 0 of an empty vec.
* We shouldn't have been using ImageDataType::decode for window
background images
* Make the fallback/placeholder black rather than fully transparent
in the more modern decoder thread routine that we use for image
decoding at the gui layer.
refs: #3614
Attempting to run when SURFACE_VIEW_FORMATS isn't successful,
so the alternative approach is to more gracefully report the
error.
refs: https://github.com/wez/wezterm/issues/3565
Further constrain the hiding logic for key-down events, so that
we are less likely to hide for things ctrl-shift-c when the user
is mousing around and copy/pasting.
Also, consider CapsLock to be a modifier for this and other
similar purposes.
refs: #3570
refs: #3306
The main part of the problem is that NSWindow::isZoomed lies to us
sometimes.
This is a relatively gross workaround.
Add missing invalidation after setting the content size; that prevents
janky when dragging the window between monitors.
Removed some redundant Dimensions computation from that method; nothing
ever read it.
refs: https://github.com/wez/wezterm/issues/3503
It's a little limited in the scope of its detection: we have a built-in
list of tiling WM environments and if the current one is on the list
then we set an appropriate value for this option.
The list currently has just a single entry.
