A state of '0' if a valid state for the mouse click. I'm unsure *how* we
get a 0 within this branch but I was able to reliably trigger it while
clicking and dragging. We handle the state explicitly because the `else`
prong is `unreachable`. We only handle triple clicks, and in another
function we reset to 3 if the count goes above that. Add an assert to
confirm this is the case.
Fixes#1514
We previously required all preedit inputs to fit into the small copied
message size. That's true for 99% of all inputs, but if a long pre-edit
input comes in, this may not be true. We should try the small array
fast-path but fall back to heap allocation if we must.
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.
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.
Fixes#1099
We previously applied application keypad mode logic (`ESC=` or mode 66)
whenever it was active. However, from looking at the behavior of other
terminals (xterm and foot) it appears this isn't correct.
For xterm, application keypad mode only applies unconditionally if the
keyboard mode is VT220 (`-kt vt220`). For modern terminals, application
keypad mode is only applied if mode 1035 is disabled.
Mode 1035 is the "ignore numpad state with keypad mode" mode. It
defaults to true on terminal startup. If this is true, keypads are
always encoded in numerical mode. If this is false, the numlock state
will be respected.
