mirror of
https://github.com/ghostty-org/ghostty.git
synced 2026-05-20 12:01:34 +00:00
macOS: "option-as-alt" defaults to "true" for US keyboard layouts
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!
This commit is contained in:
@@ -1574,20 +1574,41 @@ keybind: Keybinds = .{},
|
||||
/// editor, etc.
|
||||
@"macos-titlebar-proxy-icon": MacTitlebarProxyIcon = .visible,
|
||||
|
||||
/// If `true`, the *Option* key will be treated as *Alt*. This makes terminal
|
||||
/// sequences expecting *Alt* to work properly, but will break Unicode input
|
||||
/// sequences on macOS if you use them via the *Alt* key. You may set this to
|
||||
/// `false` to restore the macOS *Alt* key unicode sequences but this will break
|
||||
/// terminal sequences expecting *Alt* to work.
|
||||
/// macOS doesn't have a distinct "alt" key and instead has the "option"
|
||||
/// key which behaves slightly differently. On macOS by default, the
|
||||
/// option key plus a character will sometimes produces a Unicode character.
|
||||
/// For example, on US standard layouts option-b produces "∫". This may be
|
||||
/// undesirable if you want to use "option" as an "alt" key for keybindings
|
||||
/// in terminal programs or shells.
|
||||
///
|
||||
/// The values `left` or `right` enable this for the left or right *Option*
|
||||
/// key, respectively.
|
||||
/// This configuration lets you change the behavior so that option is treated
|
||||
/// as alt.
|
||||
///
|
||||
/// The default behavior (unset) will depend on your active keyboard
|
||||
/// layout. If your keyboard layout is one of the keyboard layouts listed
|
||||
/// below, then the default value is "true". Otherwise, the default
|
||||
/// value is "false". Keyboard layouts with a default value of "true" are:
|
||||
///
|
||||
/// - U.S. Standard
|
||||
/// - U.S. International
|
||||
///
|
||||
/// Note that if an *Option*-sequence doesn't produce a printable character, it
|
||||
/// will be treated as *Alt* regardless of this setting. (i.e. `alt+ctrl+a`).
|
||||
///
|
||||
/// Explicit values that can be set:
|
||||
///
|
||||
/// If `true`, the *Option* key will be treated as *Alt*. This makes terminal
|
||||
/// sequences expecting *Alt* to work properly, but will break Unicode input
|
||||
/// sequences on macOS if you use them via the *Alt* key.
|
||||
///
|
||||
/// You may set this to `false` to restore the macOS *Alt* key unicode
|
||||
/// sequences but this will break terminal sequences expecting *Alt* to work.
|
||||
///
|
||||
/// The values `left` or `right` enable this for the left or right *Option*
|
||||
/// key, respectively.
|
||||
///
|
||||
/// This does not work with GLFW builds.
|
||||
@"macos-option-as-alt": OptionAsAlt = .false,
|
||||
@"macos-option-as-alt": ?OptionAsAlt = null,
|
||||
|
||||
/// Whether to enable the macOS window shadow. The default value is true.
|
||||
/// With some window managers and window transparency settings, you may
|
||||
|
||||
Reference in New Issue
Block a user