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.
Dingbats are generally symbolic glyphs that frequently overflow the
cell. Their defined codepoint width is "1" so they take one cell but
very often overflow to the next.
This extends the previously created logic for Nerd Font symbols such
that when a dingbat is next to whitespace, we allow it to use the full
size, but when a dingbat is next to an occupied cell we constrain it to
the cell size.
Many applications use Xft.dpi to scale their contents (e.g. Chromium,
kitty, alacritty...). This value also gets set by DE setting managers
and can be manually set in ~/.Xresources if using, e.g., i3.
This should make HiDPI on Linux more consistent even when not using
GTK-specific methods (e.g. GDK_SCALE=2).
Note that we still consider GTK scaling, so it's possible to use the two
independently.
Closes#1243
The clear_screen binding does nothing on the alternate screen already,
but we were still marking the action as "performed" which caused the
binding to be consumed.
This meant that alt screen applications like neovim, tmux, etc. couldn't
see "cmd+k" (default binding for clear_screen on macOS) without the
Ghostty user unbinding it completely.
We already have other bindings that do not consume only when they do not
perform, such as `previous_tab` and `next_tab`. This extends the
framework we built for that to this action.
Up to this point, every font I've experienced with ligatures has
replaced the codepoints that were replaced for combining with a space.
For example, if a font has a ligature for "!=" to turn it into a glyph,
it'd shape to `[not equal glyph, space]`, so it'd still take up two
cells, allowing us to style both.
Monaspace, however, does not do this. It turns "!=" into `[not equal
glyph]` so styles like backgrounds, underlines, etc. were not extending.
This commit detects multi-cell glyphs and inserts synthetic blank cells
so that styling returns. I decided to do this via synthetic blank cells
instead of introducing a `cell_width` to the shaper result because this
simplifies the renderers to assume each shaper cell is one cell. We can
change this later if we need to.
Annoyingly, this does make the shaper slightly slower for EVERYONE to
accomodate one known font that behaves this way. I haven't benchmarked
it but my belief is that the performance impact will be negligible
because to figure out cell width we're only accessing subsequent cells
so they're likely to be in the CPU cache and also 99% of cells are going
to be width 1.
Fixes#139
From the issue:
Looking into this now, I think I figured out the broken logic. When launching
from open, the parent process of Ghostty is launchd which appears to set your
SHELL env var to your configured shell when logging in. That's why a restart
fixes it. However, I believe directory services (the macOS equivalent to
/etc/passwd) is updated in real time.
Ghostty does read directory services but at a lower priority than SHELL.
This logic makes sense for CLI-launched terminals but not desktop-launched.
From a CLI you want the terminal you're launching to probably inherit the shell
from the CLI you launched it from. (Note that using open explicitly forces a
launchd-style launch so it quacks as if it was double-clicked on the desktop).
In conclusion, I believe the correct logic is to invert the priority on SHELL
vs directory services when Ghostty detects it was launched from launchd. We
already have this detection logic in Ghostty because we use it for a number of
other things as well, so this should be easy to fix. I'll work on it later
today.
Rather than immediately converting a color palette index into an RGB
value for a cell color, when a palette color is used track the palette
color directly in the cell state and convert to an RGB value in the
renderer.
This causes palette color changes to take effect immediately instead of
only for newly drawn cells.
Fixes#1198
This adds a fix similar to what we discovered with termio messages: we
attempt to send a surface message but if the queue is full we unlock the
terminal state and try again waiting forever.
In all cases, its safe to unlock the mutex while sending the message, no
scenario we send a surface message requires this lock to be held.
