Follow-up to #8445, after a messed up rebase in #8339 brought it back
alongside an extra section.
All text removed from CONTRIBUTING.md was identical to the version
present in HACKING.md (according to a textual diff), excluding the
“Developer Guide” heading, the callout under it, and the “Nix VM
Integration Tests” section introduced in #8339.
Follow up to #8289
The rise of agentic programming has eliminated the natural effort-based
backpressure that previously limited low-effort contributions. It is
now too easy to create large amounts of bad content with minimal effort.
Open source projects have always had poor quality issues, PRs, etc. That
comes with the territory. Unfortunately, the ease and carelessness by which
these are now manifested has increased the "bad" count by 10x if not more.
It's ruining it for the rest of us. This policy is a result of the bad, and
I'm sorry about it.
**Going forward, AI generated contributions will only be allowed for
accepted issues and maintainers.** Drive-by pull requests with AI generated
content will be immediately closed.
**Going further, users who contribute bad AI generated content will be
immediately banned from all future contributions.** This is a zero-tolerance
policy. If you use AI, you are responsible for the quality of your
contributions. If you're using low-effort AI to create low-effort content,
I have no human obligation to help you.
If you are a junior developer who is really trying to learn and get
better, then please put aside the AI, do your best, and I will still
help. I want to help. But I expect effort and organic thinking in return.
This is not an anti-AI stance. This is an anti-idiot stance. Ghostty is
written with plenty of AI assistance and many of our maintainers use
AI daily. We just want quality contributions, regardless of how they are
made.
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.
