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
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
