search

wez / wezterm

A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust
https://wezfurlong.org/wezterm/
Other
16.93k stars 762 forks source link

Can't get German umlauts working with typical macOS keystrokes #5569

Open cug opened 3 months ago

cug commented 3 months ago

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

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

pejax commented 3 months ago

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.

cug commented 3 months ago

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.

BhawickJain commented 2 months ago

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.

rudionrails commented 2 months ago

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

BhawickJain commented 2 months ago

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!

cug commented 2 months ago

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

"but this can be configured"

How?

bluen commented 2 months ago

#3866 mentions setting config.send_composed_key_when_left_alt_is_pressed = true

That fixed it for me.