Fixes#1618
Font sizes in configuration were always a u8, but the keybinding and
internal state was a u16 so it allowed for an ever-growing font size. At
a certain point, there is an integer overflow which causes it to wrap
around. This is all silly, 255 should be large enough for anyone[1]
[1]: Ready to be super wrong about this
Ghostty does not report associated text on macOS when
macos-option-as-alt is enabled for _any_ key press, whether or not the
Alt modifier is actually present. The "option as alt" decision should
only be made when the alt modifier is present.
This follows a specific behavior Kitty has, but no other terminal seems
to have, but it is a reasonable behavior that is in use by real programs
as found by our beta testing community.
We diverge from Kitty though in that we only apply this to ASCII
letters. Kitty does not CSIu encode special characters like `@` or `$`.
For these characters, Ghostty still encodes it as specified by fixterms.
Related to #1507
The comments in this change have most of the detail. The primary gist:
- caps-lock is handled correctly so #1501 is still fixed
- only characters pressed with the shift key are affected
Fixes#1505
I verified this behavior with every other terminal and I've added test
cases for it. We previously had a test case to assert the opposite,
which is incorrect.
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.
Previously, we encoded `ctrl+_` in the CSIu format[1]. This breaks most
notably emacs which expects the legacy ambiguous encoding.
This commit utilizes the generator from Kitty to generate our control
key mappings. We also switch from keycode mapping to key contents
mapping which appears to be the correct behavior also compared to other
terminals.
In the course of doing this, I also found one bug with our fixterms
implementation. Fixterms states: "The Shift key should not be considered
as a modifier for Unicode characters, because it is most likely used to
obtain the character in the first place (e.g. the shift key is often
required to obtain the ! symbol)." We were not applying that logic and
now do.
[1]: https://www.leonerd.org.uk/hacks/fixterms/
This gets `zig build -Dtarget=aarch64-ios` working. By "working" I mean
it produces an object file without compiler errors. However, the object
file certainly isn't useful since it uses a number of features that will
not work in the iOS sandbox.
This is just an experiment more than anything to see how hard it would be to
get libghostty working within iOS to render a terminal. Note iOS doesn't
support ptys so this wouldn't be a true on-device terminal. The
challenge right now is to just get a terminal rendering (not usable).
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.
Associated text should only be reported when it was generated from the
key event. To my knowledge, there are no release events which produce
text. This now matches kitty reporting for release events.
> When the key event is related to an actual modifier key, the corresponding
> modifier's bit must be set to the modifier state including the effect for the
> current event. For example, when pressing the :kbd:`LEFT_CONTROL` key, the
> ``ctrl`` bit must be set and when releasing it, it must be reset. When both
> left and right control keys are pressed and one is released, the release event
> must have the ``ctrl`` bit set. See :iss:`6913` for discussion of this design.
Fixes#1052
This implements a `close_all_windows` binding in the core and implements
it for macOS specifically. This will ask for close confirmation if any
surface in any of the windows requires confirmation.
This is bound by default to option+shift+command+w to match Safari. The
binding is generall option+command+w but users may expect this to also
mean "Close All Other Tabs" which is the changed behavior if any tabs
are present in a standard macOS application. So I chose to follow Safari
instead.
This doesn't implement this feature for GTK, that's left as an exercise
for a contributor.
This allows bindings with `tab` to work properly on Linux. The issue is
that in the key translation, we weren't mapping this and thought it was
invalid IME input so we were ignoring it.
This work is mainly targeted at adding the crosshair for when
ctrl/super+alt is pressed. We also add this for when mouse tracking is
enabled so that we show the crosshair when ctrl/super+alt+shift is
pressed at the same time.
I've also changed the event processing logic here because the amount of
keys we have to process has greatly increased. Instead of processing
each individual event, we now process the modifier state.
Additionally, some refactoring has been done geared at starting to
re-work the mouse for the core surface into a something stateful. My
hope is that we can continue to unravel some of this from the core
surface so that we can process key inputs, motion events, and anything
else relevant as inputs to transitions for shape display, click
behavior, etc.
This commit now also moves the ctrlOrSuper handlers to respective parts
in the Key hierarchy, while also adding additional helpers for other
modifiers.
Related to https://github.com/mitchellh/ghostty/issues/1082
This fixes two separate issues to follow along with the new spec changes
Kovid pushed to Kitty:
1. When two modifiers are pressed and one is released, this shows up
as a proper release event with the correct side. Previously, the
correct side was shown but as a press event.
2. When two modifiers are pressed and one is released, the Kitty event
should not have that specific modifier set. For example, pressing
left ctrl, then right ctrl, then releasing right ctrl should encode
as "right ctrl released" but with NO modifiers still present.
Add additional keypad keys to the encoding scheme. This allows Ghostty
to report KP_HOME and it's relatives. We also always check for a keyval
first, so we can report KP_7, etc as opposed to ASCII '7'.
