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
Don't fallback to some other serial.
In a new version of SCTK, it looks like the serial we pass should
be the serial from the time we entered the surface, rather than
the latest serial that we have.
In practice, this commit uses None for the serial which seems to
have better results, but may come back to haunt us until we upgrade
to the latest SCTK.
refs: https://github.com/wez/wezterm/issues/3334#issuecomment-1515141539
This allows for potentially listing multiple candidate cursor names,
like we do for x11, but doesn't add any.
Attempt to load default if our desired cursor is not found.
refs: https://github.com/wez/wezterm/issues/3334
For eg: RU layout, CTRL-S shouldn't result in ы in the context
of a terminal.
The approach taken here is similar to kitty; when the key combination
doesn't produce a definitive composed output, and when any of
ctrl/alt/super are present, we treat the keypress as though it were
the same as the one from the system default keymap.
The result is that ctrl-c now works like ctrl-c and alt-b and alt-f work
like their latin counterparts.
Hopefully there are no downsides to this!
refs: https://github.com/wez/wezterm/issues/2845
refs: https://github.com/kovidgoyal/kitty/issues/606
