Wezterm: Keyboard related problems on German Keyboard layout.

[mborejdo]

Describe the bug

Having played a bit with the new split functionality, I came across some keyboard-related problems:

• the default keybindings (all using SHIFT + two other modifiers) for split-related features do not work for me. It seems all combos including SHIFT+CTRL are not working and the actions are not triggered.
  this does work, though:

{key="V", mods="ALT|SHIFT", action=wezterm.action{SplitVertical={SpawnCommand={Domain=0}}}},        
{key="H", mods="ALT|SHIFT", action=wezterm.action{SplitHorizontal={SpawnCommand={Domain=0}}}},
{key="RightArrow", mods="ALT", action=wezterm.action{ActivatePaneDirection="Right"}},       
{key="LeftArrow", mods="ALT", action=wezterm.action{ActivatePaneDirection="Left"}},     
{key="UpArrow", mods="ALT", action=wezterm.action{ActivatePaneDirection="Up"}},
{key="DownArrow", mods="ALT", action=wezterm.action{ActivatePaneDirection="Down"}},
{key="RightArrow", mods="ALT|SHIFT", action=wezterm.action{AdjustPaneSize={"Right", 1}}},       
{key="LeftArrow", mods="ALT|SHIFT", action=wezterm.action{AdjustPaneSize={"Left", 1}}},
{key="UpArrow", mods="ALT|SHIFT", action=wezterm.action{AdjustPaneSize={"Up", 1}}},
{key="DownArrow", mods="ALT|SHIFT", action=wezterm.action{AdjustPaneSize={"Down", 1}}}

• additionally I found these keys also not working in wezterm: ` ' ^ (dead keys, red in Image)

Environment (please complete the following information):

• OS: Windows 10, German Keyboard-layout
• Version: wezterm 20200909-002054-4c9af461-21-g7b855fb

Configuration

• no special keyboard-related settings

[wez]

I'll look at this in more detail when I next fire up my windows environment.
FWIW, this is the "right" way to specify the domain for the split action:

wezterm.action{SplitHorizontal={domain="CurrentPaneDomain"}}

and I don't know if you saw this, but in https://github.com/wez/wezterm/commit/3383bc568423e316c96f388513ac9591f856243b I added action="TogglePaneZoomState"

[wez]

I think current master has addressed both of these concerns. I'm not 100% sure about dead key support, but it seems to behave consistently with the standard console window for me with my basic on-screen keyboard test.

[mborejdo]

Thanks, I can confirm the dead-keys on my german keyboard work. Thanks for fixing this!

[bew]

Quoting the commit message of 5088c62

Specifically, using the on-screen keyboard, if I click ^ then click e wezterm will emit ê. If I click ^ then ^ then wezterm emits ^^.

How to send ^ to the terminal then? Or ^e, which can be used in *vim to go to the end of the first word of the line?

I know it looks like https://xkcd.com/1172/ 😂 but can you add an option to disable this behavior on windows?

[wez]

Quoting the commit message of 5088c62

Specifically, using the on-screen keyboard, if I click ^ then click e wezterm will emit ê. If I click ^ then ^ then wezterm emits ^^.

How to send ^ to the terminal then? Or ^e, which can be used in *vim to go to the end of the first word of the line?

All I know is that that behavior is consistent with what I saw in the old fashioned native windows terminal with CMD.
I don't know that I'd call it great behavior, and I'm not sure that my test environment matches a real DEU keyboard with deadkeys.

I would have expected ^^ to send just ^ based on what I read on MSDN.

What is a reasonable behavior here? Does it make sense to have an option to disable dead keys? I'm not sure that I can guarantee to know when a key press might be a dead key based on how Windows' text input processing works. If I can get ^^ to send just a single ^ is that workable?

[bew]

Could you maybe check what happens on the new Microsoft Terminal?
I'd rather compare wezterm to this new modern terminal, than to the old CMD.

[wez]

I'm interested to hear about how people that have dead keys and that use terminals would expect things to behave; the closest I can get to this is clicking things on an on-screen keyboard that looks more like my phone software keyboard than a real keyboard (complete with german language predictions!), and in a language/layout that is literally foreign to me. I have no idea what reasonable really means in this context!

The new windows terminal uses a different set of APIs that are higher level than the raw windows messages, so the code there isn't especially useful to draw upon. I did look at Putty's implementation, but that has its own way to second-guess the windows text input layer, and it wasn't clear to me really what options made sense to users.

So: I'm definitely open to changing this for the better, but I need to know what better means :-)

[bew]

Does it make sense to have an option to disable dead keys?

This would be ideal for me, but I know I'm a bit extreme in some of my wishes/workflows related to key bindings.

If I can get ^^ to send just a single ^ is that workable?

On my work computer, french layout so with a few dead keys, dead keys seems to be handled by windows, BEFORE being sent to any program. I can't test wezterm unfortunately because we don't have the minimum windows version required to have pty and support wezterm, but I'm working on that!

I actually had to work around the automatic dead keys behavior of windows with a few AutoHotKey scripts. I think I'm the only person of the few teams around me to have "solved" the annoying auto-dead key system for now..

FYI (and from what I remember), the auto dead key behavior is that ` + space sends `, and ` + anything sends the combined char if it makes sense, or both chars otherwise.

I had to "fix" ` and ^ only though if I remember correctly.

From what I understand, wezterm uses lowlevel hooks on the keys, so this whole auto-dead key behavior should not happen, right?
On my side (I guess you now know what I think about this^^) I'm expecting raw keys to be sent to the programs in the terminal, without char guesses like dead keys done by the os etc..

[wez]

I don't think it is feasible to change how dead keys are handled without taking on responsibility of knowing everything about keyboard layouts. The best I can see how to do after playing around a bit today is to non-deterministically override the behavior. The first few ^ seem to be overrideable, but after pressing enter some hidden state in the keyboard layout machinery emits 3 ^ on each subsequent press of ^, which isn't especially useful.

From what I've seen on a quick google around is that other users are compiling their own layout dlls that have dead keys disabled.
That seems like the "best" solution from a system-wide perspective, albeit impossible if you lack administrative privileges.

A lot of text input processing has implicit state in win32; as soon as TranslateMessage gets involved somewhere, the system "does stuff" that is totally opaque to the application. TranslateMessage is necessary to provide a number of system related keyboard expansion; there isn't a way to pick and choose which pieces you want.

[bew]

Argh windows.....
So would an option to disable dead key handling in wezterm be enough? Or do you think there is something else to do?