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
This is a working tentative at fixing text expansion/injection done by
Espanso by default, where XKB doesn't seem to detect the pressed
modifiers `Ctrl+Shift` before pressing `v`.
refs: #3840
Weirdly, the rust compiler is suddenly complaining about this,
when this file hasn't changed.
```
error[E0283]: type annotations needed
--> window\src\os\windows\window.rs:2398:26
|
2398 | if vk <= u8::MAX.into() {
| -- ^^^^
| |
| type must be known at this point
|
= note: cannot satisfy `u32: PartialOrd<_>`
help: try using a fully qualified path to specify the expected types
|
2398 | if vk <= <u8 as Into<T>>::into(u8::MAX) {
| ++++++++++++++++++++++ ~
error[E0283]: type annotations needed
--> window\src\os\windows\window.rs:2415:32
|
2415 | if leader.1 <= u8::MAX.into() && key.1 <= u8::MAX.into() {
| -- ^^^^
| |
| type must be known at this point
|
= note: cannot satisfy `u32: PartialOrd<_>`
help: try using a fully qualified path to specify the expected types
|
2415 | if leader.1 <= <u8 as Into<T>>::into(u8::MAX) && key.1 <= u8::MAX.into() {
| ++++++++++++++++++++++ ~
```
Note that this also does not respect dpi_by_screen; this is for
consistency in behavior and reported values.
Once we can produce the correct overridden value in
dispatch_pending_event, we can update these functions to return
the same data.
refs: #4096
This is a baby step towards handling dpi_by_screen.
I don't want to do the actualy per-screen stuff here;
it touches stuff around the edges of SCTK and there is a pending,
significant, rewrite of that code needed to upgrade to a more
recent version of SCTK + wayland-protocols, and I don't want to waste
my effort on the intermediate state.
https://github.com/wez/wezterm/issues/3996#issuecomment-1636830740
refs: #4096
Maintain a cache of the positions of the various named screens,
and use that to resolve the screen of the current window, and
from there we can resolve the correct dpi_by_screen screen.
Make dpi and dpi_by_screen config changes generate a resize
event with the updated dpi.
refs: #4096
Allows specifying the precise dpi to use on a per-screen basis:
```lua
return {
dpi_by_screen = {
["Built-in Retina Display"] = 144,
},
}
```
The screen names are the same as those returned from
`wezterm.gui.screens()`.
Changing either `dpi` or `dpi_by_screen` in the config will now cause
the window to be immediately resized/adjusted to the changed dpi
override.
Ultimately, I'd like to deprecate `dpi` in favor of `dpi_by_screen`,
but can't do that until this functionality is ported to windows, x11
and wayland.
refs: #4096
