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.
This adds to the heuristics introduced for #1071. Please read that issue
and associated PRs in their entirety to understand this commit.
This extends our concept of "whitespace" to include powerline box
glyphs. We don't want to constrain nerd symbols next to powerline box
glyphs because box glyphs are often used to style and contain nerd
glyphs. For example, its common to see a right-facing semi-circle, then
a nerd font glyph, then a left-facing semi-circle to create a
pill-shaped label.
This allows those nerd font symbols to be rendered full size. Test
script below (copy the bytes):
printf "\n"
printf " \n"
printf "\n"
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 codepath was not previously tested (an accident). Upon testing
this codepath its clear to see the logic was incorrect. When we have to
remove rows from our scrollback to fit new rows in the circular buffer,
we have to delete graphemes, but we were deleting them from the wrong
row offset.
For the row offset, we previously used the _active_ screen but the
proper offset is the _full_ screen. Tests verify.
Fixes#1356 correctly.
This was previously fixed by #1360 which just assigned a random
placement ID. I asked the Kitty maintainer about this and this is not
the correct logic and the spec has been updated.
When a placement ID of zero is sent, we allow multiple placements but
use an internal, non-addressable placement ID. The issue with my
previous approach was someone with knowledge of internals (or luck)
could technically address the placement. This isn't allowed.
Fixes#1366
When we use `loadTheme`, we "replay" the configuration so that the theme
is the base configuration and everything else can override everything
the theme sets. During this process, we were not properly re-expanding
all the relative paths.
This fix works by changing our input tracking from solely tracking args
to tracking operations such as expansion as well. When we "replay" the
configuration we also replay operations such as path expansion with the
correct base path.
This also removes the `_inputs` special mechanism `cli/args.zig` had
because we can already do that ourselves using `parseManuallyHook`.
