Wezterm: Can't type [, ] or {, } on my extenal Norwegian bluetooth keyboard

[erf]

Describe the bug

I have an macbook pro with english keys, but sometimes i use an external Norwegian bluetooth keyboard, and now i noticed i can't type the characters []{} using my normal keyboard shortcuts which works on iTerm and Terminal app.

Environment (please complete the following information):

• OS: macOS
• Frontend: OpenGL
• Version: WezTerm-macos-20200202-200216-b07ed454-40-g7d27499 ( can't run wezterm -V maybe add an about GUI box from menu with version no ? )

To Reproduce

Usually i press Option+8 and Option+9 to show [ and ].

And i press Shift+Option+8 and Shift+Option+9 to show { and }.

Configuration

I have disabled the .wezterm.toml file.

Expected behavior

I would expect the correct characters to appear.

Instead nothing happens.. except Option+9 show a the following:

Select a tab and press Enter to activate it. Press Escape to cancel.
1. wezterm

[wez]

(Regarding running wezterm from the cli: you can find the wezterm executable inside the app bundle; eg: run WezTerm.app/wezterm -V)

Two things to try, in this order:

1. Start wezterm like this: RUST_LOG=trace wezterm. This will run with a log of debug output. Then press the key combinations that are not functioning for you. Capture the log lines that contain key_common and report them here.

2. Try setting use_ime = false in your .wezterm.toml file, restarting wezterm (this option is one of the few that requires a restart to take effect), and see if that helps.

[wez]

Regarding the very last part of what you wrote: you're activating the tab selection overlay which is bound to ALT-9 by default. You can de-assign it like this:

[[keys]]
key = "9"
mods = "ALT"
action = "Nop"

[erf]

Ok, here is the log result from typing []{} ( i set ALT-9 as suggested )

2020-02-16T16:14:09.465Z DEBUG window::os::macos::window           > key_common: chars=`[` unmod=`8` modifiers=`ALT` virtual_key=28
 2020-02-16T16:14:09.465Z DEBUG window::os::macos::window           > key_common KeyEvent { key: Char('['), raw_key: Some(Char('8')), modifiers: ALT, repeat_count: 1, key_is_down: true } (chars="[" unmod="8" modifiers=ALT
 2020-02-16T16:14:10.165Z DEBUG window::os::macos::window           > key_common: chars=`]` unmod=`9` modifiers=`ALT` virtual_key=25
 2020-02-16T16:14:10.165Z DEBUG window::os::macos::window           > key_common KeyEvent { key: Char(']'), raw_key: Some(Char('9')), modifiers: ALT, repeat_count: 1, key_is_down: true } (chars="]" unmod="9" modifiers=ALT
 2020-02-16T16:14:11.874Z DEBUG window::os::macos::window           > key_common: chars=`{` unmod=`(` modifiers=`SHIFT | ALT` virtual_key=28
 2020-02-16T16:14:11.874Z DEBUG window::os::macos::window           > key_common KeyEvent { key: Char('{'), raw_key: Some(Char('(')), modifiers: SHIFT | ALT, repeat_count: 1, key_is_down: true } (chars="{" unmod="(" modifiers=SHIFT | ALT
 2020-02-16T16:14:12.610Z DEBUG window::os::macos::window           > key_common: chars=`}` unmod=`)` modifiers=`SHIFT | ALT` virtual_key=25
 2020-02-16T16:14:12.610Z DEBUG window::os::macos::window           > key_common KeyEvent { key: Char('}'), raw_key: Some(Char(')')), modifiers: SHIFT | ALT, repeat_count: 1, key_is_down: true } (chars="}" unmod=")" modifiers=SHIFT | ALT

Setting use_ime = false did not help.

[wez]

What's happening is that the key is being treated as ALT-9 instead of the Norwegian key composed value. You can see this if you run od -c and press those key combinations.

The same thing happens with an English keymap selected; eg: ALT-1:

key_common KeyEvent { key: Char('¡'), raw_key: Some(Char('1')), modifiers: ALT, repeat_count: 1, key_is_down: true } (chars="¡" unmod="1" modifiers=ALT

In this case, it is almost always desirable for native English speakers to have ALT-1 be treated as ALT-1 rather than ¡, and that is what makes this tricky to resolve automatically; how can wezterm know the right thing to do in all contexts?

For the moment, while I think on this, I'd suggest explicitly configuring wezterm to send the sequences that you want (and also see the example at the bottom of https://wezfurlong.org/wezterm/config/keys.html): key below is compared to the raw_key value from the debug output you shared previously:

[[keys]]
key = "8"
mods = "ALT"
action = "SendString"
arg = "["

[[keys]]
key = "9"
mods = "ALT"
action = "SendString"
arg = "]"

[[keys]]
key = "("
mods = "ALT|SHIFT"
action = "SendString"
arg = "{"

[[keys]]
key = ")"
mods = "ALT|SHIFT"
action = "SendString"
arg = "}"

[erf]

I tried your key combinations, but only [] worked, not {}.

Also when i try to output the | key by pressing OPT+7, i have the same problem.

I understand this is a difficult problem, but it seem to work out of the box in other editors, so maybe there is a way to solve it.

[wez]

Sorry, for the shifted keys I used the English keymap version rather than the raw_key values you pasted; I've updated the comment above to use ( and ) for those.

Re: solving it: yes, there is a way to solve it: it needs some thought and some configuration options, and it will take a bit of time to come up with it.

[erf]

The following worked for me:

[[keys]]
key = "("
mods = "ALT|SHIFT"
action = "SendString"
arg = "{"

[[keys]]
key = ")"
mods = "ALT|SHIFT"
action = "SendString"
arg = "}"

[wez]

Ah, I changed the wrong field! I re-edited my comment above

[mborejdo]

I am having problems with wezterm and my german macbook keyboard. Currently Key-combos like Option+l (@ symbol) dont work. Same for other right-options keys.

[wez]

I was peeking at this to refresh my memory, and noticed this undocumented option. Can you try setting:

return {
   send_composed_key_when_alt_is_pressed = true,
}

and see if that helps? I have to make sure that my LANG=en_US.utf-8 is set in order for my shell to correctly interpret the character that ALT-1 generates for me. The important part is making sure that you have a UTF-8 variation of your locale selected, not that it be en_US.

[mborejdo]

I made sure the correct utf-8 locale is set. But unfortunately this did not help. Also the suggested config-setting did not help. With the setting the Option+l did send something (::1 broadcasthost localhost) in bash, but it was not the "@" symbol.

[wez]

I've pushed a commit that I think will help; it's not in master yet because I most likely need to fixup the linux and windows builds to accommodate the changes.

You should be able to find a build here when it completes in ~20 minutes:
https://github.com/wez/wezterm/actions/runs/117975644

The behavior should be that when send_composed_key_when_alt_is_pressed = true in your config, that you get the desired output.

I can see that both the macos Terminal.app and iTerm both default to sending the composed keys and I think that perhaps wezterm should default to the same to make this easier, but first I want to make sure that we're getting the right information and then we can decide on the defaults!

[erf]

Seem to work for me now (on macOS)! Thanks!

[mborejdo]

The behavior should be that when send_composed_key_when_alt_is_pressed = true in your config, that you get the desired output.

Yea, I can also confirm that. Sending @ on (german) macos works. Thanks a lot!

[erf]

send_composed_key_when_alt_is_pressed does not seem to work anymore, but send_composed_key_when_left_alt_is_pressed does.

[wez]

The behavior did change, but it should be for the better; this section in the docs explains the new default behavior:

https://wezfurlong.org/wezterm/config/keys.html#alt--option-key-behavior--composed-keys