Bug
EventMonitor.run() in src/textual/drivers/win32.py (~line 273) has a filter:
if key_event.dwControlKeyState and key_event.wVirtualKeyCode == 0:
continueThis assumes any event with VK=0 + modifier keys held is a "bare modifier" noise event that can be safely dropped.
Counterexample
Under Chinese/Japanese/Korean IME, pressing Shift+? produces an IME composition event with: VK=0x0000, UnicodeChar=U+FF1F, dwControlKeyState=SHIFT_PRESSED. This event IS the only delivery of the intended character — there is no follow-up event with VK≠0. The filter drops it, so CJK IME users cannot type any symbol requiring Shift.
Environment
- Windows 10/11
- Chinese (Simplified) IME, Microsoft Pinyin
- Textual >= 2.x
Fix
Add a check that only discards events without a valid Unicode character:
if (
key_event.dwControlKeyState
and key_event.wVirtualKeyCode == 0
and (not key or key == "\x00")
):
continuekey is the str from chr(key_event.uChar.UnicodeChar) — if the IME produced a real character (like U+FF1F), key will be non-empty and non-null.
Bug
EventMonitor.run()insrc/textual/drivers/win32.py(~line 273) has a filter:This assumes any event with VK=0 + modifier keys held is a "bare modifier" noise event that can be safely dropped.
Counterexample
Under Chinese/Japanese/Korean IME, pressing Shift+? produces an IME composition event with:
VK=0x0000,UnicodeChar=U+FF1F,dwControlKeyState=SHIFT_PRESSED. This event IS the only delivery of the intended character — there is no follow-up event with VK≠0. The filter drops it, so CJK IME users cannot type any symbol requiring Shift.Environment
Fix
Add a check that only discards events without a valid Unicode character:
keyis thestrfromchr(key_event.uChar.UnicodeChar)— if the IME produced a real character (like U+FF1F),keywill be non-empty and non-null.