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!
Fixes#2908
When loading `config-file`, we need to ensure that all loaded
configuration is loaded _prior_ to any `-e` values from the CLI.
To do this, I inserted a new `-e` special tag type in our replay steps.
This can be used to find when `-e` starts and ensure it remains at the
end of replay steps when the replay steps are being modified.
This commit also found a similar (but not exercised) issue where this
could happen with light/dark themeing.
Related to #2775
This makes it so that `changeConditionalState` only does something if
the conditional state (1) has changes and (2) those changes are relevant
to the current conditional state.
By "relevant" we mean that the conditional state being changed is state
that is actually used by the configuration.
Fixes#2791
This goes back to the previous implementation of clone that directly
cloned values rather than using replay steps, because replay steps don't
preserve conditionals on the iterator.
This works.
Another fix will be when we support some sort of conditional syntax and
the replay iterator can yield that information. We have a unit test here
so we can verify that then.
Only lines which contain (optional) whitespace followed by a # character
are comments. We should not treat lines like "foreground = #aaa" as
containing a comment.
Fixes#2695
We had various issues with the pointerVisible property on macOS,
including the pointer not being hidden when it should be. Our only use
case today is mouse hide while typing so
NSCursor.setHiddenUntilMouseMoves is a better fit!
Fixes#2601
It is more expected behavior that `-e` affects only the first window. By
introducing a dedicated configuration we avoid making `-e` too magical:
its simply syntax sugar for setting the "initial-command" configuration.
