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
It's not clear exactly how this triggers, but in setups where
a compose key has been configured (against the default for the
configured keyboard layout), it seems as though certain events
that indicate when composition is complete are not delivered,
leaving the compose cursor in an inconsistent state.
This commit attempts to detect that composing->!composing
state transition and bubble it up; when we return Nothing
and had previously had a composition string we're return
a bool to cause the caller to emit an event that clears
the composition state.
I'm not totally sure this is 100% right, but I think
it may help with the case we're discussing in
https://github.com/wez/wezterm/issues/4841
We have two different ways to compose:
* Via xkbd
* Via IME messages
In the latter case, we receive notifications from the IME about
the composed text, but are apparently not guaranteed to receive
them about the composition status overall.
This commit will synthesize clearing the composition status
when we receive the instruction to emit composed text.
The hope is that this will clear the compose cursor state
that appears to get stuck for some users of ibus + Gnome 45.
refs: https://github.com/wez/wezterm/issues/4841
