wezterm

wezterm copied to clipboard

What Operating System(s) are you seeing this problem on?

macOS

Which Wayland compositor or X11 Window manager(s) are you using?

macOS standard

WezTerm version

20240615-054200-1533409e aarch64-apple-darwin

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

Background: I'm used to typing German umlaut characters in the typical way on macOS with a US keyboard by pressing Option-u and then the actual character, e.g. a to get ä.

This works in all applications I'm using, including iTerm2 and Alacritty. It does not work with WezTerm.

To complicate matters: I'm also using a Kinesis Advantage 360 ergonomic keyboard and have programmed the above sequence to Fn1-a and it works as a macro. Again, even this works in all other terminal apps I currently have installed.

I did try with the MacBook Air internal keyboard, same results. Works everywhere, does not work in WezTerm.

To Reproduce

• Use macOS
• Use US keyboard
• Type German umlaut in typical way with Opt-u, then the actual letter to convert to umlaut

Configuration

I blindly tried config from here:

https://github.com/wez/wezterm/issues/410

without understanding whether the given hints should work in my case or not. They did not make a difference. I have otherwise no relevant config set that I know of that should influence this.

Expected Behavior

Umlauts working like everywhere else on macOS

Logs

Debug Overlay wezterm version: 20240615-054200-1533409e aarch64-apple-darwin Window Environment: macOS 14.5 (23F79) Lua Version: Lua 5.4 OpenGL: Apple M2 4.1 Metal - 88.1 Enter lua statements or expressions and hit Enter. Press ESC or CTRL-D to exit

Anything else?

No response

Same here - I also failed/did not understand how to add a key binding workaround. This keeps me from making the final switch from Alacritty to WezTerm.

Yeah, I was using Wezterm for a test run, but since I'm using tmux, the integrated multiplexer in Wezterm doesn't do much for me and the umlaut situation forces me off Wezterm. I'm using Alacritty now since iTerm2 takes a constant 2% CPU load on my machine and I need to maximize battery runtime.

Possibly related, whilst migrating to WezTerm, I found that any macOS OPT-<some-char> are not emitted as literal special characters. For example in Alacritty OPT-t gives me a literal char †, but on WezTerm it appears to be interpreted as an escape key press. So this general observation includes the umlaut issue.

This is related to #3866. The right OPTION key will behave as expected on macOS, but this can be configured

This is related to #3866. The right OPTION key will behave as expected on macOS, but this can be configured

I can confirm that my right OPTION key gives me the umlaut behaviour as expected. I did not change my config. Thanks @rudionrails!

Confirmed here as well, right option seems to work for my use case, but:

"but this can be configured"

How?

#3866 mentions setting config.send_composed_key_when_left_alt_is_pressed = true

That fixed it for me.

Did not fix anything here.

Hey @cug,

I think your existing config is interfering with that setting. I have copied my config (omitting some odd bits) and have tested it -- in which this definitely works with this setting on:

-- $HOME/config/wezterm/wezterm.lua

local wezterm = require 'wezterm'
local config = {}


config.send_composed_key_when_left_alt_is_pressed = true
config.font_size                     = 16
config.hide_tab_bar_if_only_one_tab  = true
config.hide_mouse_cursor_when_typing = true
config.default_cursor_style          = 'SteadyBlock'
config.window_decorations            = "RESIZE"
config.window_background_opacity     = 0.80
config.macos_window_background_blur  = 20
config.audible_bell                  = 'Disabled'
config.window_close_confirmation = 'NeverPrompt'


return config

I am thinking broadly what could be wrong; make sure you have deleted the current config on your system, and work backwards. Possibly left-alt is not being fired because of the keyboard or some other keyboard config software.

Aaaaah, now I found it. I missed this one:

-- config.use_dead_keys = false

with it commented out, and these two:

config.send_composed_key_when_left_alt_is_pressed = true
config.send_composed_key_when_right_alt_is_pressed = false

set I can now:

• write umlauts with the left alt/opt key (or use my Kinesis macro which uses left-opt)
• switch between panes/splits with right alt/opt + a motion key (jikl in my case)

This works. Thank you! If there is nothing left here, I think we can close this. "use_dead_keys" was my problem. Thanks for all the help and sorry for the noise here.

And again I'm reminded to never start from someones else's base config ...

PS: And just in case someone is wondering why I want umlauts in my terminal: it's so much nicer to use them in LaTeX instead of "a or such, plus I often pre-write longer notes and emails in nvim, and some of them are in German. So this helps a lot.

I'm also unable to type "ö" (umlaut o) using the dead key combination (Option+U, then O). After navigating several potentially relevant documents and issues (including this one), I tried the configuration below, which I expected to work. Could there be something I’m missing or overlooking? I confirmed that I can type ö in iTerm2, so I believe there is no interference between the terminal and other externals.

local wezterm = require("wezterm")
local config = wezterm.config_builder()
config.send_composed_key_when_left_alt_is_pressed = true
config.send_composed_key_when_right_alt_is_pressed = true
config.use_dead_keys = true
-- although I hope to use IME
config.use_ime = false
return config

---

wezterm 20241205-083533-6f375e29 macOS 15.1.1 MacBook Pro 2021, US layout

Not sure and can’t test since I’m currently traveling. Looks close enough to my config. Have you tried replacing your config with the one from Bhawick? That worked for me and I then looked for differences and slowly added my config back in.

Sorry to interrupt your trip. I've tried Bhawick's configuration, but it didn’t work for me.

I solved my problem. It occurred because I was using the English mode of the Japanese input method as my English input method (Kotoeri.RomajiTyping.Roman). After switching to the standard English input method (ABC), I can now use dead keys. I'm sorry to trouble you.

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.