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
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
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
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.
This pulls in almost all of the original PR in #2235.
I skipped a dead key case that I recall being tricky:
I didn't want to break the non win32-input mode version
of that.
I'd be happy to have that case re-evaluated in a smaller
PR where we can focus on its details.
Co-authored-by: Dominik Kreutzer <kreudom@gmail.com>
