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
* Removed title update from main render loop
* Add to PaneFocused event
* term: only emit Alert::OutputSinceFocusLost for the first
seqno bump after losing focus, rather than on every bump.
That event indirectly causes the title to update
refs: https://github.com/wez/wezterm/issues/4788
This used to make things such that the copy button for `console`
blocks would only copy the input and not the output, but it
doesn't seem to have that effect any more, and now just prevents
selecting portions of the output.
That's a PITA because eg: the CLI --help pages use `console`
to show which options are available.
I think something has probably changed somewhere in upstream mkdocs
because this used to work as I mentioned above.
refs: https://github.com/squidfunk/mkdocs-material/issues/6697
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
DiffState keeps track of a virtual cursor in order to skip emitting
cursor location changes when a previous text change has already moved
the cursor to the desired position. However, currently the code always
advances the cursor by 1 column for each added text change regardless
of the width of the text.
Fix behavior by advancing the cursor by the width of the text.
To avoid having to add a new variable, make 'self.cursor' contain
the cursor position for the next cell instead of the current cell.
In addition, add a test verifying the behavior.
