Fixes#1416
At a high level, the issue is that when mouse capture is enabled (i.e. in
neovim), "shift" escapes the capture. So "cmd+shift" is equal to "cmd"
which doesn't get sent to the TUI program and so on. For link
highlighting which now requires "cmd" (super) is held, we were sending
"cmd+shift" to the renderer so we weren't checking for links.
So the core of this commit is respecting this scenario and stripping the
shift modifier.
This commit also found that when the mouse wasn't over a link, we were
always checking and highlighting links on line one of the visible
screen. This bug is fixed and should also result in a very slight
performance improvement on rendering in all cases.
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.
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.
