This is a fairly large rework of how we handle the sprite font drawing.
Drawing routines are now context-less, provided only a canvas and some
metrics. There is now a separate file per unicode block / PUA area.
Sprites are now drawn on canvases with an extra quarter-cell of padding
on each edge, and automatically cropped when sent to the atlas, this
allows sprites to extend past cell boundaries which makes it possible to
have, for example, diagonal box drawing characters that connect across
cell diagonals instead of being pinched in.
Most of the sprites the code is just directly ported from the old code,
but I've rewritten a handful. Moving forward, I'd like to rewrite more
of these since the way they're currently written isn't ideal.
This rework, in addition to improving the packing efficiency of sprites
on the atlas, and allowing for out-of-cell drawing, will make it a lot
easier to add new sprites in the future, since all it takes now is to
add a single function and an import (if it's a new file).
I reworked the regression/change testing to be more robust as well, it
now covers all sprite glyphs (except non-codepoint ones) and does so at
4 different sizes. Addition/removal of glyphs will no longer create diff
noise in the generated diff image, since the position in the image of
each glyph is now fixed.
Adds the config option as described in #4515.
Plumbed it into the `RunIterator` and updated all the tests that rely on
that, adding additional cases to the cursor boundary tests where I found
them.
Closes#4515
This is an extension agreed upon by modern terminals to indicate that
they support copying to the clipboard with XTerm's OSC 52 sequence. It
is only reported when writing to the clipboard is actually allowed.
Ref: #7590
This test-only function wraps testWriteString with semantic prompt
marking. This replaces the manual, row-based semantic_prompt field
manipulation we were doing in all of our prompt-related test setups.
This function's heuristics are a little complex because it wraps
testWriteString as a "black box"; we don't benefit from that function's
own line-based logic to know which rows need to be updated with the
semantic prompt flag. We need to infer them externally instead.
I considered adding an options argument to testWriteString that would
allow passing e.g. a semantic_prompt prompt. Given that it's called from
200+ places, that would involve a lot of unrelated changes, but it
remains an "option" (ha!) if there's value there for other cases.
I also have plans that move us from row-based to cell-based semantic
tracking, where the current semantic type is tracked by the cursor. In
that implementation, testWriteString can update the written cells
directly, and testWriteSemanticString just helps manage the cursor's
state. Introducing testWriteSemanticString here and now therefore helps
bridge us to that world while maintaining test consistency.
Fixes#7724
Background at the end of the commit message. The fix in libxev is
described in the PR and commit we pin to here, but basically we swap
read for poll for eventfd/timerfd. libxev commit:
75a10d0fb3
From Jens Axboe on X:
> This will fix it: https://pastebin.com/n7JSZWpW which makes me
suspicious
> that it's an S_IFREG check somewhere else, as anon inodes are now
listed as
> regular files. Has potentially pretty broad implications...
> I think I can already answer why that breaks things - io_uring checks
if
> this is a regular file, and if it is, it doesn't do short reads. Short
> reads on regular files (or a bdev) will cause application issues, as
> basically nobody expects them.
> Now we have what acts like a char dev, but where io_uring will retry
IO
> because the application asked for more data than what was delivered.
This
> will cause the weird slowdowns as data isn't delivered as soon as it's
> available.
## Backporting to 1.1.3
It's a bit risky, but we can back port the libxev update to 1.1.3 (and
release a 1.1.4) since we don't plan on a 1.2 release for a couple
months. Realistically, we've been running the latest libxev on tip
(before this commit) for awhile and there haven't been issues so I think
it's safe enough.
I think we should let this merge settle for a few days at least before
we do that back port though.
This PR introduces support for Irish (Gaeilge), the first official
language of Ireland and an EU working language.
The translation file was initialized using the standard gettext tooling:
` msginit -i po/com.mitchellh.ghostty.pot -l $LANG -o "po/$LANG.po"`
The locale code `ga_IE` follows ISO standards for Gaeilge as spoken in
Ireland.
I'm happy to volunteer as the ongoing maintainer of the Irish
translation and will keep it up to date as Ghostty evolves.
Go raibh maith agat!
This test-only function wraps testWriteString with semantic prompt
marking. This replaces the manual, row-based semantic_prompt field
manipulation we were doing in all of our prompt-related test setups.
This function's heuristics are a little complex because it wraps
testWriteString as a "black box"; we don't benefit from that function's
own line-based logic to know which rows need to be updated with the
semantic prompt flag. We need to infer them externally instead.
I considered adding an options argument to testWriteString that would
allow passing e.g. a semantic_prompt prompt. Given that it's called from
200+ places, that would involve a lot of unrelated changes, but it
remains an "option" (ha!) if there's value there for other cases.
I also have plans that move us from row-based to cell-based semantic
tracking, where the current semantic type is tracked by the cursor. In
that implementation, testWriteString can update the written cells
directly, and testWriteSemanticString just helps manage the cursor's
state. Introducing testWriteSemanticString here and now therefore helps
bridge us to that world while maintaining test consistency.
Fixes#7724
Background at the end of the commit message. The fix in libxev is
described in the PR and commit we pin to here, but basically we swap
read for poll for eventfd/timerfd.
From Jens Axboe on X:
> This will fix it: https://pastebin.com/n7JSZWpW which makes me suspicious
> that it's an S_IFREG check somewhere else, as anon inodes are now listed as
> regular files. Has potentially pretty broad implications...
> I think I can already answer why that breaks things - io_uring checks if
> this is a regular file, and if it is, it doesn't do short reads. Short
> reads on regular files (or a bdev) will cause application issues, as
> basically nobody expects them.
> Now we have what acts like a char dev, but where io_uring will retry IO
> because the application asked for more data than what was delivered. This
> will cause the weird slowdowns as data isn't delivered as soon as it's
> available.
This is an extension agreed upon by modern terminals to indicate that
they support copying to the clipboard with XTerm's OSC 52 sequence. It
is only reported when writing to the clipboard is actually allowed.
This introduces an action for copying the path of a written
screen/selection file into the clipboard.
Pasting the path into the terminal doesn't work well if you have a
program still running and opening the file outside the terminal (on
macOS in TextEdit by default) isn't always a great experience.
Allowing to copy the file path into the clipboard seems like a minor and
hopefully uncontroversial addition. 😅
Fix regression from d44a6cde2c7ed59f0f28fad16e6b760d7529ebee where we
halted parsing on deprecated fields, which was not the intended
behavior.
This commit fixes that and adds a test to verify it.
Fix regression from d44a6cde2c7ed59f0f28fad16e6b760d7529ebee where
we halted parsing on deprecated fields, which was not the intended
behavior.
This commit fixes that and adds a test to verify it.
Fixes#7706
We previously had a very specific backwards compatibility handler for
handling renamed fields. We always knew that wouldn't scale but I wanted
to wait for a real case. Well, #7706 is a real case, so here we are.
This commit makes our backwards compatibility handler more general
purpose, and makes a special-case handler for renamed fields built on
top of this same general purpose system. The new system lets us do a lot
more with regards to backwards compatibility.
To start, this addresses #7706 by allowing us to handle a removed single
enum value of a still-existing field.
In the future, I think this may continue to get _more_ general purpose
by moving the handlers from functions to structs so we can have more
metadata like descriptions and so on that we may use to generate docs or
other help strings.
Fixes#7706
We previously had a very specific backwards compatibility handler for
handling renamed fields. We always knew that wouldn't scale but I wanted
to wait for a real case. Well, #7706 is a real case, so here we are.
This commit makes our backwards compatibility handler more general
purpose, and makes a special-case handler for renamed fields built on
top of this same general purpose system. The new system lets us do a lot
more with regards to backwards compatibility.
To start, this addresses #7706 by allowing us to handle a removed single
enum value of a still-existing field.
Supersedes #7154
In gtk4-layer-shell versions < 1.0.4, the app could crash upon opening a
quick terminal window on certain compositors that implement the
`xdg_wm_dialog_v1` protocol. The exact reason is a bit complicated, but
is nicely summarized in the upstream issue (wmww/gtk4-layer-shell#50).
The circumstances that could cause this crash to occur should gradually
diminish as distros update to newer gtk4-layer-shell versions, but this
is known to crash on Fedora 41 and Hyprland, which could be a sizable
chunk of our userbase given that this would also occur on GNOME/Mutter
and KDE/KWin. The diff should be minimal enough that this can be removed
or reverted once this band-aid fix is no longer necessary.
Supersedes #7154
In gtk4-layer-shell versions < 1.0.4, the app could crash upon opening
a quick terminal window on certain compositors that implement the
`xdg_wm_dialog_v1` protocol. The exact reason is a bit complicated,
but is nicely summarized in the upstream issue (wmww/gtk4-layer-shell#50).
The circumstances that could cause this crash to occur should gradually
diminish as distros update to newer gtk4-layer-shell versions, but this
is known to crash on Fedora 41 and Hyprland, which could be a sizable
chunk of our userbase given that this would also occur on GNOME/Mutter
and KDE/KWin. The diff should be minimal enough that this can be removed
or reverted once this band-aid fix is no longer necessary.
