Fixes#1833
This is an attempt to simplify the logic that has organically grown
convoluted over time with regards to how the titlebar and tab bar is
styled.
This field is one unified field that ONLY addresses titlebar and tab bar
styling. It can be one of "native", "transparent", or "tabs". The
"native" field is the new behavior in this commit: it makes the titlebar
and tab bar appearance be absolutely native. We do not color anything
(if we do its a bug).
The "transparent" option is the previous `macos-titlebar-tabs = false`
setting where the titlebar/tab bar is native but colored according to
the window background color.
The "tabs" option is `macos-titlebar-tabs = true`.
The `window-theme = auto` affect on titlebar appearance has been
removed. Now, the titlebar will NEVER be styled with "native" and MAY be
styled with "transparent" and will ALWAYS be styled with "tabs" (since
that's a totally custom look anyways).
The alias handling block only handles one alias, which is already
handled in the switch statement. Remove this block and rename all
references to 'action' back to 'input'.
Fixes#1724
See background in #1724. The general idea is that for Ghostty
invocations via xdg-terminal-exec, we set the initial title to the
command automatically so that window managers can modify the styling.
We only do this for xdg-terminal-exec because that protocol/spec is
specifically for the scenario that the terminal is being used to launch
a command from the desktop environment.
For now, bash integration must be explicitly enabled (by setting
`shell-integration = bash`). Our automatic shell integration requires
bash version 4 or later, and systems like macOS continue to ship bash
version 3 by default. This approach avoids the cost of performing a
runtime version check.
Related to #1802
CSIu format sends a unicode codepoint but we were just sending the first
byte of the utf8 sequence, which is very much not right. This fixes that
by parsing the utf-8.
It isn't defined what to do if the utf-8 sequence is invalid or has
multiple codepoints so we just skip CSIu encoding in that case.
Reproduction: HU layout Ctrl+ő
On release, we were previously not sending an alt text (we were sending
it properly on press). Kitty sends it also on release and the spec makes
it clear we should send it on release. This was just due to some faulty
logic; added a test and fixed that.
Fixes#1802
This allows `keybind` configurations to map to any Unicode codepoint. This enables keybindings for which we don't have a registered keycode or for custom keyboard firmwares that may produce arbitrary text (but the Ghostty support is limited to a single codepoint).
The `keybind` syntax is unchanged. If a bound character doesn't map to a known logical key that Ghostty knows about, we map it to a Unicode codepoint. The unicode codepoint is compared against the _unshifted codepoint_ from the apprt key event.
Note that this binding is to a single _codepoint_. We don't support arbitrary sequences of characters or multi-code point graphemes for keybindings due to the complexity in memory management that would introduce.
This also provides a good fallback for scenarios where it might make sense to educate Ghostty about a key code or fix a bug in our keyboard input system, but the unicode data is correct. In that scenario, unicode key binds should allow key binds to still work while we investigate the input issues.
Example:
```
shift+ö=text:hello
```
This now works as expected on a US hardware keyboard with the Hungarian keyboard layout.
Some opener commands (like macOS's open) finish immediately after
running, while others (xdg-open) do not, staying alive until the
application that was opened itself terminates.
For now, we explicitly state whether or not we should wait for a
command. Eventually we may want to do something more generic (e.g. wait
for some predetermined amount of time and if the process does not
complete, give up without collecting stderr).
