- wgpu gives segfault so move to EGL
- implement terminating message loop to match prev implementation
- still gives error but no segfault or panic right now
The workaround was to allow ctrl-c to behave as expected for users
of cyrillic layouts, but it was scoped too broadly, as it impacted
eg: pressing ctrl-grave; in a spanish layout that is expected to
expand to º
This commit adjusts the scope of the workaround to only activate
when the original expansion is itself cyrillic.
I doubt this is the last we'll hear of this, but let's see
how it goes!
refs: https://github.com/wez/wezterm/issues/4933
I'm not sure if this is the right way to go about this, but it doesn't
immediately break some simple tests with non-us layouts for me, so
I'm willing to push it and see what people say.
refs: https://github.com/wez/wezterm/issues/4910
It's important not to clobber the layout number, and we need to
pass through more of the modifier bits from the X event, so we
just pass them all through wholesale.
refs: https://github.com/wez/wezterm/issues/4864
Depending on the amount of padding, we could previously resize to get a
negative size displayed by the window manager's overlay (e.g., 80x-1 for
a very short window displaying zero terminal lines and only partially
showing the top of the tabs). We would also like to avoid 80x0 or 0x24
dimensions as these can render funny. For example, when there is a lot
of padding, an 80x0 size can still show part of the top of the first
line despite it being a cell height of zero.
On X11, this information is set as part of the hints given to the window
manager. When resizing the terminal, many X11 window managers will now
correctly report the current cell size of the terminal (e.g., 80x24) as
an overlay when resizing the window.
test scenario is:
```
bash -c "sleep 5; for((i=0;i<30;i++)); do xdotool keydown --delay 0 Shift_L keydown --delay 0 9 keyup --delay 0 Shift_L keyup --delay 0 9; done"
```
That should cause a series of `(` characters to be emitted, but prior to
this commit is was usually mostly `9`'s.
What's changing here is:
* We copy the pertinent fields from the last xcb StateNotify event.
That ostensibly has the current modifier and layout state, but
because it comes from the X server, it doesn't factor in knowledge
from the IME.
* When processing an XCB key event, compute the current modifier
mask and override the XKB state with it.
* Now XKB will produce correct information about the key syms
* Restore the modifier state from the saved StateNotify information.
refs: https://github.com/wez/wezterm/pull/4151
refs: https://github.com/wez/wezterm/issues/4615
refs: https://github.com/fcitx/fcitx5/issues/893
refs: https://github.com/ibus/ibus/issues/2600
refs: https://github.com/wez/wezterm/issues/3840
this partially reverts eb3a78b0cb and
should hopefully resolve the underlying problem, which is that
the composition cursor is stuck at an empty string when using
a compose key on its own.
refs: https://github.com/wez/wezterm/issues/4841
