After typing an accented letter, WezTerm cursor keeps showing the accent mode until WezTerm is restarted

[sorashi]

What Operating System(s) are you seeing this problem on?

Linux X11

Which Wayland compositor or X11 Window manager(s) are you using?

Gnome 45.3

WezTerm version

20240121-180215-76028ca1

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Typing an accented letter leaves it inside the cursor until wezterm is restarted. The issue is shell-independent and thus I conclude it's a bug in wezterm. See the attached screen recording.

wezterm-accent.webm

To Reproduce

1. Use the IBUS input method framework
2. Select the Czech keyboard layout
3. Press Shift+= (where the = normally is in an English layout). This enters the "ˇ accent mode" and expects a letter next. Wezterm cursor correctly displays ˇ.
4. Type a letter (for example t). This results in ť and leaves the "accent mode".
5. Wezterm cursor still displays ˇ.

The same issue occurs with ´, ¨, and possibly other accents.

Configuration

no config

Expected Behavior

Wezterm cursor should stop displaying ˇ after leaving accent mode.

Logs

No response

Anything else?

This problem is relevant when typing in the language with accents in a terminal text editor, like vim.

[wimstefan]

I can confirm that behaviour with Xorg configured compose key like that

Section "InputClass"
  Identifier "libinput keyboard catchall"
  MatchIsKeyboard "on"
  MatchDevicePath "/dev/input/event*"
  Driver "libinput"
  Option "XkbOptions" "compose:ralt,terminate:ctrl_alt_bksp"
EndSection

[wez]

I can't reproduce this, so I suspect there's another factor at play. I'm on Gnome 42.9 (ubuntu), but otherwise: yes, have ibus enabled and the steps above seem to work to correctly produce the accented character and then the compose cursor returns to normal.

Please run wezterm with the following trace env set:

WEZTERM_LOG=window::os::x11::keyboard=trace,info wezterm --config debug_key_events=true

then run through those repro steps again and share what gets logged.

[sorashi]

@wez here it is, hope it helps

16:52:27.369  INFO   wezterm_gui::termwindow::keyevent > key_event RawKeyEvent { key: Physical(RightShift), modifiers: SHIFT, leds: (empty), phys_code: Some(RightShift), raw_code: 62, repeat_count: 1, key_is_down: true, handled: Handled(false) } 
16:52:27.369  TRACE  window::os::x11::keyboard         > process_key_event: RawKeyEvent FeedResult::Nothing: "", 65506. kc -> None fallback_feed=Nothing("", 65506)
16:52:27.369  INFO   wezterm_gui::termwindow::keyevent > key_event KeyEvent { key: RightShift, modifiers: SHIFT, leds: (empty), repeat_count: 1, key_is_down: true, raw: Some(RawKeyEvent { key: Physical(RightShift), modifiers: SHIFT, leds: (empty), phys_code: Some(RightShift), raw_code: 62, repeat_count: 1, key_is_down: true, handled: Handled(false) }) } 
16:52:27.369  INFO   wezterm_gui::termwindow::keyevent > send to pane DOWN key=RightShift mods=SHIFT
16:52:27.564  TRACE  window::os::x11::keyboard         > keysym_to_keycode for 65114 and 65114 -> None
16:52:27.596  INFO   wezterm_gui::termwindow::keyevent > key_event KeyEvent { key: RightShift, modifiers: SHIFT, leds: (empty), repeat_count: 1, key_is_down: false, raw: Some(RawKeyEvent { key: Physical(RightShift), modifiers: SHIFT, leds: (empty), phys_code: Some(RightShift), raw_code: 62, repeat_count: 1, key_is_down: false, handled: Handled(false) }) } 
16:52:27.596  INFO   wezterm_gui::termwindow::keyevent > send to pane UP key=RightShift mods=SHIFT
16:52:28.010  INFO   wezterm_gui::termwindow::keyevent > key_event KeyEvent { key: Composed("ť"), modifiers: NONE, leds: (empty), repeat_count: 1, key_is_down: true, raw: None } 
16:52:28.010  INFO   wezterm_gui::termwindow::keyevent > send to pane DOWN key=Char('ť') mods=NONE
16:52:28.010  INFO   wezterm_term::terminalstate::keyboard > key_down: sending "ť", Char('ť') NONE
16:52:28.081  INFO   wezterm_gui::termwindow::keyevent     > key_event KeyEvent { key: Char('t'), modifiers: NONE, leds: (empty), repeat_count: 1, key_is_down: false, raw: Some(RawKeyEvent { key: Physical(T), modifiers: NONE, leds: (empty), phys_code: Some(T), raw_code: 28, repeat_count: 1, key_is_down: false, handled: Handled(false) }) } 
16:52:28.081  INFO   wezterm_gui::termwindow::keyevent     > send to pane UP key=Char('t') mods=NONE
16:52:31.421  INFO   wezterm_gui::termwindow::keyevent     > key_event RawKeyEvent { key: Physical(Space), modifiers: NONE, leds: (empty), phys_code: Some(Space), raw_code: 65, repeat_count: 1, key_is_down: true, handled: Handled(false) } 
16:52:31.421  TRACE  window::os::x11::keyboard             > process_key_event: RawKeyEvent FeedResult::Nothing: " ", 32. kc -> Some(Char(' ')) fallback_feed=Nothing(" ", 32)
16:52:31.421  INFO   wezterm_gui::termwindow::keyevent     > key_event KeyEvent { key: Char(' '), modifiers: NONE, leds: (empty), repeat_count: 1, key_is_down: true, raw: Some(RawKeyEvent { key: Physical(Space), modifiers: NONE, leds: (empty), phys_code: Some(Space), raw_code: 65, repeat_count: 1, key_is_down: true, handled: Handled(false) }) } 
16:52:31.421  INFO   wezterm_gui::termwindow::keyevent     > send to pane DOWN key=Char(' ') mods=NONE
16:52:31.421  INFO   wezterm_term::terminalstate::keyboard > key_down: sending " ", Char(' ') NONE
16:52:31.492  INFO   wezterm_gui::termwindow::keyevent     > key_event KeyEvent { key: Char(' '), modifiers: NONE, leds: (empty), repeat_count: 1, key_is_down: false, raw: Some(RawKeyEvent { key: Physical(Space), modifiers: NONE, leds: (empty), phys_code: Some(Space), raw_code: 65, repeat_count: 1, key_is_down: false, handled: Handled(false) }) } 
16:52:31.492  INFO   wezterm_gui::termwindow::keyevent     > send to pane UP key=Char(' ') mods=NONE

[wez]

Hmm, inconclusive.
Let's try this; it will be more verbose, especially if you move your mouse over the window:

WEZTERM_LOG=window::os::x11::keyboard=trace,wezterm_gui::termwindow=trace,wezterm_gui::termwindow::render=info,wezterm_gui::termwindow::mouseevent=info,info wezterm -n --config debug_key_events=true

the lines to pay the most attention to will look like this:

09:12:53.636  DEBUG  wezterm_gui::termwindow           > AdviseDeadKeyStatus(Composing("^"))
09:12:53.636  INFO   wezterm_gui::termwindow           > DeadKeyStatus now: Composing("^")

but I would like to see all of them

[wimstefan]

Here is the log of the last command: https://dpaste.org/R5OA0

[sorashi]

@wez done too, here it is (the messages you mention are lines 289-290):

https://gist.github.com/sorashi/746e87aff885bdbe756d8fb1808fbe70#file-wez-log-L289-L290

[wez]

I've pushed a commit to main that may help with this; it'll show up in nightly builds in about 20-30 minutes, or you can build from source if you prefer.
Please let me know how it works out!

[sorashi]

@wez After building 02bdd7e I can confirm the issue is gone! Thank you for your work 😄

[wimstefan]

Unfortunately I can't report that it's solved with xkbd :(
The issue is still present on my system with X.Org X Server 1.21.1.11 and awesome WM ...

[sorashi]

Ok, reopened for you @wimstefan

[wez]

@wimstefan I think you might be technically experiencing a different issue, or rather, that perhaps some of this issue is really another manifestation of:

• x11: Use modifiers from X event if none were detected by XKB #4151
• Lost "Shift" when using QMK layers for shifted keys ibus/ibus#2600

I've pushed a commit that adds a new config option that I'd like you to try: x11_use_passive_key_updates=false. That will use a slightly different way of updating the keyboard state and may help with this.

[wimstefan]

I've pulled the latest commits, compiled wezterm and added the new config option but the problem remains the same ...
Anything else I can do?

[wez]

@wimstefan is the behavior the same in the last released version? Understanding whether this is a regression or a longstanding issue will help focus where to look

[wez]

@wimstefan I've pushed a couple more changes:

• removed that x11_use_passive_key_updates option
• added the dead key status to the normal debug key events mode, to take it less of a chore to observe it
• added some logic to synthesize clearing the composition state in this case, where we don't get a signal to clear it from the WM/IME/KBD

[wimstefan]

@wez With that version (20240123-150250-eb3a78b0) the first key of the composed keys is not kept in the cursor anymore but I'm still not able to write a composed character like "í" ...
If you wish I can download the latest binary from https://wezfurlong.org/wezterm/install/linux.html#raw-linux-binary and see how that works.

[wez]

@wimstefan oh, so composition isn't actually working in your case? Was that how it was before this most recent change?

[wimstefan]

I just noticed that behaviour a couple of days ago and chimed into this issue since I thought I'm experiencing the same problem.

I've installed now the official Gentoo release (20230712-072601-f4abf8fd-gentoo) and the composed keys like "í" are working as expected ...

[wez]

Can you try building 90d8fea from source and see if the issue exists there?
If that does work correct, then try 0466898 (the next commit) to see if that was what introduced the issue for you

[wez]

and if that isn't conclusive, it would be great if you could run a git bisect between f4abf8fd (the working revision you installed from gentoo) and main!

[wimstefan]

OK I'll do that tomorrow morning - now it's 1.30am here and bedtime 😏

[wimstefan]

With 90d8fea the composition key works, 0466898 as well, it stops working with 72fae51 ...

[wez]

Ah, interesting! Ok, I think 079e87d may resolve this!

[wimstefan]

And it is fixed indeed!
Many thanks for the time and effort you've put into fixing this!!!
And for the whole project of course :)

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.