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.
This fixes#7702 by no longer passing the arena allocator to a task that
outlives its caller.
As far as I can tell, a reference to `config_path` may live on in the
`argv` field of the ChildProcess after the arena is cleared (unless
`argv` itself becomes a dangling pointer because the literal it's
referencing goes out of scope? Struggling to wrap my head around some of
the finer points of Zig array/slice/literal semantics). However, I
suppose it's safe to assume that `argv` is never referenced after
`exe.spawn()` has returned, in which case there's no issue. If this were
a problem, it would apply equally to all uses of `internal_os.open`, not
just the open config code path.
Closes#6632
When compiling the dynamic lib and linking, the rpath resolves to the
compile cache location instead of the install location for the lib. This
resulted in loading the dylib failing when the compile cache was removed
or the install location is changed.
Based on https://github.com/ziglang/zig/issues/5827 , we specify the
rpath to search relative to the executable.
Previous state:
- dynamic lib was not installed to the output directory -> now appears
in `$OUT/lib/libgtk4-layer-shell.so`
- rpath only included the compile cache location, not the install
location.
Before:
```sh
$ patchelf --print-rpath zig-out/bin/ghostty
/home/anthony/dev/ghostty-pure/.zig-cache/o/0254fb4753185c5429180337a720248d
$ ldd zig-out/bin/ghostty
...
libgtk4-layer-shell.so => /home/anthony/dev/ghostty-pure/.zig-cache/o/0254fb4753185c5429180337a720248d/libgtk4-layer-shell.so (0x00007f7975468000)
...
$ ldd zig-out/bin/ghostty
...
libgtk4-layer-shell.so => not found
...
```
After:
```sh
$ zig build
$ patchelf --print-rpath zig-out/bin/ghostty
/home/anthony/dev/ghostty/.zig-cache/o/f45360ddde653cb3bc70966c326dd96d:$ORIGIN/../lib/
$ ldd zig-out/bin/ghostty
...
libgtk4-layer-shell.so => /home/anthony/dev/ghostty/.zig-cache/o/f45360ddde653cb3bc70966c326dd96d/libgtk4-layer-shell.so (0x00007fbf81ad8000)
...
$ rm -r .zig-cache/
$ ldd zig-out/bin/ghostty
...
libgtk4-layer-shell.so => /home/anthony/dev/ghostty/zig-out/bin/../lib/libgtk4-layer-shell.so (0x00007f60dc087000)
...
```
