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
