When one develops Ghostty while using Ghostty it could lead to an
interesting conundrum: the freshly built Ghostty would use the parent
Ghostty's resources, which would be stale and not reflect any new
changes to resources. This is especially bad for translators, since
their translations would not be reflected in the newly built Ghostty
if they happen to run it under older Ghostty, which is not only
counterintuitive and also painful in terms of workflow.
Now, on debug builds we always try to use the terminfo detection method
first in order to locate the zig-out/share/ghostty folder, and only fall
back to GHOSTTY_RESOURCES_DIR if the executable is for some reason no
longer in zig-out. You can test this behavior by manually moving the
Ghostty executable out of zig-out, and then launching it with and without
Ghostty.
This is my third (!) attempt at implementing localization support.
By leveraging GTK builder to do most of the `gettext` calls, I
can avoid the whole mess about missing symbols on non-glibc platforms.
Added some documentation too for contributors and translators,
just for good measure.
Elvish integration is broken when running `sudo`, because the function
`sudo-with-terminfo` uses `command` command, which is not implemented in
Elvish. Changing it to `external` command should fix possible error when
bypassing aliases, functions and builtins, like `command` does in Bash.
Discussion about this issue: #5979
Also I updated documentation about Elvish integration to provide fix
when using `use ghostty-integration` outside of Ghostty with `rc.elv`.
Note that for Debian 12, the blueprints must be compiled on a distro
with a newer version of `blueprint-compiler` and the raw UI XML
committed to git. Debian 12 includes `blueprint-compiler` 0.6.0 which
doesn't support compiling `adw.MessageDialog` even though the version of
`libadwaita` supports it.
In docs option reference, for macos-icon info. It is showing two times
similar thing. And Note looks good instead of just text because it wont
work without `custom-style`. So a Big Note is a good highlight.
There's been *far* too many people who aren't aware of the new
dependency, and that is partly our fault: a "FileNotFound" error is
quite obtuse, unless you religiously follow every PR and every commit
made to the repository. Instead of shepherding everyone who runs into
this manually, we should offer better signposting.
There's been *far* too many people who aren't aware of the new dependency,
and that is partly our fault: a "FileNotFound" error is quite obtuse,
unless you religiously follow every PR and every commit made to the
repository. Instead of shepherding everyone who runs into this manually,
we should offer better signposting.
Fixes#5927
This doesn't fix the underlying reason that GTK sometimes reports
content scales as negative. If GTK reports a negative scale, we ignore
that and use 1.0 for the scale.
See #5930
Kakoune sends a real SGR sequence with 17 parameters. Our previous max
was 16 so we threw away the entire sequence. This commit increases the
max rather than fundamentally addressing limitations.
Practically, it took us this long to witness a real world sequence that
exceeded our previous limit. We may need to revisit this in the future,
but this is an easy fix for now.
In the future, as the comment states in this diff, we should probably
look into a rare slow path where we heap allocate to accept up to some
larger size (but still would need a cap to avoid DoS). For now,
increasing to 24 slightly increases our memory usage but shouldn't
result in any real world issues.
This should resolve#5938.
I tested this locally using `zig build -D=emit-docs=true` and confirmed
that the mdgen process provided the new manpages in
`zig-out/share/man/man*`, respectively.
Let me know if this needs any changes, I tried to keep this as similar
as possible to the existing manpages (both format and content).
See #5930
Kakoune sends a real SGR sequence with 17 parameters. Our previous max
was 16 so we through away the entire sequence. This commit increases the
max rather than fundamentally addressing limitations.
Practically, it took us this long to witness a real world sequence that
exceeded our previous limit. We may need to revisit this in the future,
but this is an easy fix for now.
In the future, as the comment states in this diff, we should probably
look into a rare slow path where we heap allocate to accept up to some
larger size (but still would need a cap to avoid DoS). For now,
increasing to 24 slightly increases our memory usage but shouldn't
result in any real world issues.
