This adds a couple of Nix-based VM integration tests:
- Does `ghostty +version` run successfully?
- Can we create a new terminal window? (This is detected by setting the
background to a color that doesn't appear
normally on the desktop and seeing if we can detect that color in a
screenshot).
Obviously more can be done but I thought that these would be a couple of
good first steps.
The whole test suite can be run with `nix flake check`. Individual tests
can be run with a command like this:
```
nix run .#check.x86_64-linux.<test name>.driver
```
I think at this point all moderators and helpers can agree with me in
that LLM-generated responses are a blight upon this Earth.
Also probably worth putting in a clause against AI-generated assets
(cf. the Commit Goods situation)
This enables agents (namely Amp) to use `/gh-issue <number/url>` to
begin diagnosing a GitHub issue, explaining the problem, and suggesting
a plan of action. This action explicitly prompts the AI to not write
code.
I've used this manually for months with good results, so now I'm
formalizing it in the repo for other contributors.
Example diagnosing #8523:
https://ampcode.com/threads/T-3e26e8cc-83d1-4e3c-9b5e-02d9111909a7
This adds two explicit `zig build` steps: `run-valgrind` and
`test-valgrind` to run the Ghostty exe or tests under Valgrind,
respectively.
This simplifies the manual Valgrind calls in a few ways:
1. It automatically sets the CPU to baseline, which is a frequent and
requirement for Valgrind on newer CPUs, and generally safe.
2. It sets up the rather complicated set of flags to call Valgrind with,
importantly setting up our suppressions.
3. It enables pairing it with the typical and comfortable workflow of
specifying extra args (with `--`) or flags like `-Dtest-filter` for
tests.
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.
Fixes#5494
When ibus/fcitx is not running (the GTK "simple" input method is
active), the preedit end event triggers _before_ the commit event. For
both ibus/fcitx, the opposite is true. We were relying on this ordering.
This commit changes the GTK input handling to not rely on this ordering.
Instead, we encode our composing state into the boolean state of whether
a key event is pressed. This happens before ANY input method events are
triggered.
Tested dead key handling on: X11/Wayland, ibus/fcitx/none.
Mitchell Hashimoto