Open wookayin opened 1 year ago
Please include the debug key events logs from https://wezfurlong.org/wezterm/troubleshooting.html#debugging-keyboard-related-issues
This happened when a type aaaaaaabbbbbb
(resulted in aaaaaaab
). I can se a bunch of b
keydown events which were not prosessed --- the first keydown of b
happened before the keyup event of a
.
I think this is a bug in the key event implementation for macos; it seems that it has something to do with macOS IME.
Setting config.use_ime = false
following a suggestion in https://github.com/wez/wezterm/issues/215#issuecomment-642746983 resolves the issue -- but this should be as only a workaround. But disabling IME kills non-English inputs (e.g. CJK with multi-byte unicode characters...)
This option appears to be enabled by default since 20220319, but this still causes a problem in key repeat as of now (macOS Ventura 13 and wezterm nightly).
On macOS, with config.use_ime = true
--- the default value, and a recommended setting so that multi-byte, non-English input (e.g. 한글, 日本語, 中文) can work properly --- users will need the following setting:
# Use key repeat instead of the accents menu when holding a key
defaults write NSGlobalDomain ApplePressAndHoldEnabled -bool false
(See https://macos-defaults.com/misc/applepressandholdenabled.html for more information about the option)
Alternatively, if one doesn't wish this option enabled globally, one can also do per-app config such as:
defaults write com.github.wez.wezterm ApplePressAndHoldEnabled -bool false
This would be only a workaroun; hope that in the future we could have a proper fix for the broken successive key repeats, because many other apps would work OK even without this setting.
I press j
and k
constantly as a fidget spinner in Vim so this issue is noticeable (and kinda disruptive) to me. Might be a fix: #6388 .
What Operating System(s) are you seeing this problem on?
macOS
Which Wayland compositor or X11 Window manager(s) are you using?
macOS. No window manager used.
WezTerm version
wezterm 20230712-072601-f4abf8fd
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
Same in the nightly wezterm 20230726-161042.
I think the same bug as in #2452 happens again on my environments. The key repeat is stuck when pressing two keys (for a sufficient long time to repeat) in quick succession results in the second key printing one character.
It was working OK in some of the previous version.
e.g.
Actual:
To Reproduce
Same as in #2452; Go into a terminal. Press the key A on your keyboard and hold it. Release it and quickly press the letter B on the keyboard and hold it. b is only printed once, even though it should be continuously be printed.
Configuration
No config needed. Reproducible with the default (zero) config.
Expected Behavior
Expected:
Logs
No response
Anything else?