macOS: "option-as-alt" defaults to "true" for US keyboard layouts #2930
Conversation
A common issue for US-centric users of a terminal is that the "option" key on macOS is not treated as the "alt" key in the terminal. ## Background macOS does not have an "alt" key, but instead has an "option" key. The "option" key is used for a variety of purposes, but the troublesome behavior for some (and expected/desired behavior for others) is that it is used to input special characters. For example, on a US standard layout, `option-b` inputs `∫`. This is not a typically desired character when using a terminal and most users will instead expect that `option-b` maps to `alt-b` for keybinding purposes with whatever shell, TUI, editor, etc. they're using. On non-US layouts, the "option" key is a critical modifier key for inputting certain characters in the same way "shift" is a critical modifier key for inputting certain characters on US layouts. We previously tried to change the default for `macos-option-as-alt` to `left` (so that the left option key behaves as alt) because I had the wrong assumption that international users always used the right option key with terminals or were used to this. But very quickly beta users with different layouts (such as German, I believe) noted that this is not the case and broke their idiomatic input behavior. This behavior was therefore reverted. ## Solution This confusing behavior happened frequently enough that I decided to implement the more complex behavior in this commit. The new behavior is that when a US layout is active, `macos-option-as-alt` defaults to true if it is unset. When a non-US layout is active, `macos-option-as-alt` defaults to false if it is unset. This happens live as users change their keyboard layout. **An important goal of Ghostty is to have zero-config defaults** that satisfy the majority of users. Fiddling with configurations is -- for most -- an annoying task and software that works well enough out of the box is delightful. Based on surveying beta users, I believe this commit will result in less configuration for the majority of users. ## Other Terminals This behavior is unique amongst terminals as far as I know. Terminal.app, Kitty, iTerm2, Alacritty (I stopped checking there) all default to the default macOS behavior (option is option and special characters are inputted). All of the aforementioned terminals have a setting to change this behavior, identical to Ghostty (or, Ghostty identical to them perhaps since they all predate Ghostty). I couldn't find any history where users requested the behavior of defaulting this to something else for US based keyboards. That's interesting since this has come up so frequently during the Ghostty beta!
|
@mitchellh Should and would this change apply to the following input/keyboard/language setup as well? I tested the latest build, and I figured that the left Option key still acts as Option key in my case; hence I checked if my layout is indeed set to U.S. Standard or U.S. International, and it seems to be set to ANSI, but not specifically a region. 
|
|
The “ABC” keyboard is not considered US standard. |
|
Not a complaining, just a heads up... I think it is very common in Brazil and maybe other countries to use MacBooks with U.S. keyboards, I don't suggest to revert this but document this behavior very explicitly so people can update their configs if needed. I solved this fast with: I always use the right option to create those symbols, maybe this info is relevant... |
I wonder if its worth restricting this behavior to locales as well... |
|
I use Brazil as my region, so in my case it would be more accurate. |
These are my locales on macOS: $ locale
LANG="de_DE.UTF-8"
LC_COLLATE="C"
LC_CTYPE="de_DE.UTF-8"
LC_MESSAGES="C"
LC_MONETARY="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="C"
LC_ALL=I wouldn’t say there’s anything suggesting me using a U.S. keyboard layout — or the “ABC” generic ANSI layout without country flag; after rather one hour of research, I’m still not sure if there really is any difference between the U.S. keyboard layout and the “ABC” generic ANSI layout, besides not showing a country flag in the menu bar. |
|
I don't think there is a "right" solution. I just wanted to provide a data point: I use a Mac with the PL (Polish) keyboard layout. I installed ghostty and was surprised that the ctrl+alt+f shortcut which normally brought up fzf in fish doesn't work anymore. It produced "ń" instead, which is what I normally get in every app if I press alt-n. It took some searching and trying things out to encounter the Of course, ideally I'd like the best of both worlds. I tried configuring bindings to override ( |
|
@jwr I have exactly the same problem. Did you manage to solve it? |
|
With the 1.0.1 update the workaround with |
Do you want to ends with good zeroconfig defaults or good standards compatibility? Because of using ABC layout I must change this setting instead of relying on defaults. |
A common issue for US-centric users of a terminal is that the "option" key on macOS is not treated as the "alt" key in the terminal.
Background
macOS does not have an "alt" key, but instead has an "option" key. The "option" key is used for a variety of purposes, but the troublesome behavior for some (and expected/desired behavior for others) is that it is used to input special characters.
For example, on a US standard layout,
option-binputs∫. This is not a typically desired character when using a terminal and most users will instead expect thatoption-bmaps toalt-bfor keybinding purposes with whatever shell, TUI, editor, etc. they're using.On non-US layouts, the "option" key is a critical modifier key for inputting certain characters in the same way "shift" is a critical modifier key for inputting certain characters on US layouts.
We previously tried to change the default for
macos-option-as-alttoleft(so that the left option key behaves as alt) because I had the wrong assumption that international users always used the right option key with terminals or were used to this. But very quickly beta users with different layouts (such as German, I believe) noted that this is not the case and broke their idiomatic input behavior. This behavior was therefore reverted.Solution
This confusing behavior happened frequently enough that I decided to implement the more complex behavior in this commit. The new behavior is that when a US layout is active,
macos-option-as-altdefaults to true if it is unset. When a non-US layout is active,macos-option-as-altdefaults to false if it is unset. This happens live as users change their keyboard layout.An important goal of Ghostty is to have zero-config defaults that satisfy the majority of users. Fiddling with configurations is -- for most -- an annoying task and software that works well enough out of the box is delightful. Based on surveying beta users, I believe this commit will result in less configuration for the majority of users.
Other Terminals
This behavior is unique amongst terminals as far as I know. Terminal.app, Kitty, iTerm2, Alacritty (I stopped checking there) all default to the default macOS behavior (option is option and special characters are inputted).
All of the aforementioned terminals have a setting to change this behavior, identical to Ghostty (or, Ghostty identical to them perhaps since they all predate Ghostty).
I couldn't find any history where users requested the behavior of defaulting this to something else for US based keyboards. That's interesting since this has come up so frequently during the Ghostty beta!