We are also now using the `darken(by:)` implementation to generate
the split divider color on macOS, which means we'll have a consistent
rendering across iOS and macOS.
Fixes#1401
SCOSC is ambiguous with regards to DECSLRM. This commit copies the logic
of xterm: if left/right mode is enabled, then CSI S is always DECSLRM.
But if left/right mode is disabled then CSI S empty always uses SCOSC.
SCORC always works.
Fixes#1389
This is just a fun AppKit quirk. This menu item is set automatically
based on the keyboard shortcut (apparently) and when its overwritten
then its gone forever. So, let's just not set it.
Normally, when `ctrl+<character>` is pressed, such as `ctrl+z` or
`ctrl+c`, macOS (AppKit) doesn't do any key translation because that
doesn't map to any printable text on its own. Ghostty does the
translation to correctly determine the character is "z" or "c" or
whatever.
For some reason when the keyboard layout is "Dvorak - QWERTY Cmd"
specifically (_not_ plain "Dvorak") on a US layout keyboard, AppKit
decides that "ctrl+z" ("/" on a qwerty keyboard) translates to "/"...
I can't find any explanation for this.
To workaround this, this commit makes it so that if the following
conditions are true, then we IGNORE AppKit's text translation and
manually do it using UCKeyTranslate:
(1) We're on macOS specifically (not iOS, etc.)
(2) We have a key event with ONLY control pressed
This fixes `ctrl+z` on this unique Dvorak keyboard layout.
Related to #1284
This is highly GUI toolkit specific, but it is impossible to receive
events for some key releases when focus is lost while the keys are still
behind held. This commit always sends a release event for the last
pressed key when focus is lost, including each individual modifier.
On macOS, AppKit sends a key release event to a view if a prior press
event was sent, but only for non-modifier keys. This means that with
this commit (1) the full key release event is repeated but (2) modifier
release events are now properly sent.
On Linux with GTK, GTK sends modifier release events but not key release
events. This means that the behavior is inverted from macOS!
The result of this commit is that key release events _may be repeated_
on focus loss, but it ensures that all prior key+modifiers for the most
recent press event are released. This will require that TUI apps
handling release apps are idempotent in their release handling but I
don't think thats unrealistic to expect and I've already been able to
demonstrate at least Kitty sending duplicate release events in some
scenarios so this seems like a safe assumption.
A few people, including myself, many times accidentally click links by
either clicking around aimlessly or getting focus back to Ghostty that
happens to be hovering over a link.
In iTerm2, if you want links enabled, it's always Cmd+Click.
