New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keybindings not respected in CommandPalette #3470
Comments
This commit here: 500934b appears to be the last working one before the issue arises. I did some bisecting and landed on this commit here where it breaks: git bisect good
d491c736ef6e320004e62270ec18036e698ffac7 is the first bad commit
commit d491c736ef6e320004e62270ec18036e698ffac7
Author: Wez Furlong <wez@wezfurlong.org>
Date: Sat Mar 25 18:24:26 2023 -0700
When a modal is active, it gets first dibs on key processing
This fixes a surprising interaction between copy mode and the
command palette, but is also the root cause of another issue
with CharSelect mode.
refs: https://github.com/wez/wezterm/issues/2947
docs/changelog.md | 3 +++
wezterm-gui/src/termwindow/charselect.rs | 12 ++++++------
wezterm-gui/src/termwindow/keyevent.rs | 21 ++++++++++++++-------
wezterm-gui/src/termwindow/modal.rs | 2 +-
wezterm-gui/src/termwindow/palette.rs | 12 ++++++------
wezterm-gui/src/termwindow/paneselect.rs | 9 +++++----
6 files changed, 35 insertions(+), 24 deletions(-) git bisect log
git bisect start
# status: waiting for both good and bad commits
# good: [1c55ca14b0e11848b5c0cd0d31ed21b61d06eca9] macos: invalidate window when dispatching from menubar
git bisect good 1c55ca14b0e11848b5c0cd0d31ed21b61d06eca9
# status: waiting for bad commit, 1 good commit known
# bad: [69ae847273aa2b0a64bdb07cf19d3f6fbaaa6b71] windows: fix: mess up full screen mode on config reload
git bisect bad 69ae847273aa2b0a64bdb07cf19d3f6fbaaa6b71
# bad: [929e86225db2916e0e88fbc61ee703f925789bac] cheaper case insensitive compare
git bisect bad 929e86225db2916e0e88fbc61ee703f925789bac
# bad: [338174b430d0957fd0351846b006397e0bbfc4f4] mux: fix pid file locking
git bisect bad 338174b430d0957fd0351846b006397e0bbfc4f4
# bad: [9f6595d76e3d79821adaba678bd32afc03e100cf] chore: Update Cargo.lock
git bisect bad 9f6595d76e3d79821adaba678bd32afc03e100cf
# bad: [e56b169cc41f2244c2bff20381a1dc14c7574095] mux: add lua api equivalent to move-pane-to-new-tab
git bisect bad e56b169cc41f2244c2bff20381a1dc14c7574095
# bad: [59503034c795b3294d40e856820eb67fe472a74c] tidy up some debug logging
git bisect bad 59503034c795b3294d40e856820eb67fe472a74c
# bad: [d491c736ef6e320004e62270ec18036e698ffac7] When a modal is active, it gets first dibs on key processing
git bisect bad d491c736ef6e320004e62270ec18036e698ffac7
# good: [500934bc9c4c9274a0ea7914e48ab3c808d0f3f3] palette: exclude copy mode actions unless copy mode is active
git bisect good 500934bc9c4c9274a0ea7914e48ab3c808d0f3f3
# first bad commit: [d491c736ef6e320004e62270ec18036e698ffac7] When a modal is active, it gets first dibs on key processing
# good: [500934bc9c4c9274a0ea7914e48ab3c808d0f3f3] palette: exclude copy mode actions unless copy mode is active
git bisect good 500934bc9c4c9274a0ea7914e48ab3c808d0f3f3
# first bad commit: [d491c736ef6e320004e62270ec18036e698ffac7] When a modal is active, it gets first dibs on key processing |
I am having the same issue on Fedora 37 with a layout set via xkbcomp and through gnome. |
@sarphiv if you pull latest and revert |
@icecreammatt I just tried the revert. |
Can you try this patch? diff --git a/wezterm-gui/src/termwindow/keyevent.rs b/wezterm-gui/src/termwindow/keyevent.rs
index 4d67f0c6b..2484a04e9 100644
--- a/wezterm-gui/src/termwindow/keyevent.rs
+++ b/wezterm-gui/src/termwindow/keyevent.rs
@@ -287,6 +287,7 @@ impl super::TermWindow {
}
if is_down {
+ if only_key_bindings == OnlyKeyBindings::No {
if let Some(modal) = self.get_modal() {
if let Key::Code(term_key) = self.win_key_code_to_termwiz_key_code(keycode) {
let tw_raw_modifiers = window_mods_to_termwiz_mods(raw_modifiers);
@@ -300,6 +301,7 @@ impl super::TermWindow {
}
}
}
+ }
if let Some((entry, table_name)) = self.lookup_key(
pane, |
@wez The patch fixes it on my system. |
Need to defer to the second pass (when we have mapped from physical keys) before we route the key event to the modal. refs: #3470
This should be resolved now in It typically takes about an hour before commits are available as nightly builds for all platforms. Linux builds are the fastest to build and are often available within about 20 minutes. Windows and macOS builds take a bit longer. Please take a few moments to try out the fix and let me know how that works out. You can find the nightly downloads for your system in the wezterm installation docs. If you prefer to use packages provided by your distribution or package manager of choice and don't want to replace that with a nightly download, keep in mind that you can download portable packages (eg: a If you are eager and can build from source then you may be able to try this out more quickly. |
Confirmed that fixed it on MacOS too. Thanks! |
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. |
What Operating System(s) are you seeing this problem on?
macOS
Which Wayland compositor or X11 Window manager(s) are you using?
No response
WezTerm version
wezterm 20230324-233449-d60cdbf7
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
I use Colemak keybindings and noticed that when using the CommandPalette that it only responds to QWERTY despite working everywhere else. I thought this was initially working but noticed that war no longer the case now. I tried on the last non nightly release (WezTerm-macos-20230326-111934-3666303c) and with the nightly (WezTerm-macos-20230408-112425-69ae8472) I swear this was working before but maybe it never was?
To Reproduce
Set MacOS keyboard layout to Colemak:
I suspect somewhere it is maybe reading the raw keyboard codes instead of using whatever layer OSX applies on top.
Update: I was able to track down that it was working properly in this release here: WezTerm-macos-20230325-134754-1c55ca14
Commit causing issue:
I've tracked down the d491c73 causing the issue here: #3470 (comment)
Configuration
Click to expand
Expected Behavior
When invoking the CommandPalette with an alternate keyboard layout (Colemak) it should show the correct keys typed.
Logs
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: