How to contribute

Helix is open to contributions of any size. This section walks through the workflow, testing, debugging tips, and the conventions you should follow when changing code.

The canonical contributor doc is docs/CONTRIBUTING.md. The pages here expand on it with a code-tour orientation.

Pages

• Development workflow — branch, code, test, PR.
• Testing — unit, doc, and integration tests.
• Debugging — logs, common errors, troubleshooting runbook.
• Patterns and conventions — error handling, naming, transaction style, hooks.
• Tooling — cargo xtask, CI, formatters, linters.

Where good first issues live

The repository tags accessible issues with E-easy. Common starter areas:

• Tree-sitter queries — adding highlights.scm, indents.scm, textobjects.scm for a missing language. Doesn't require deep Rust knowledge.
• Themes — porting a theme from another editor. Validate with cargo xtask theme-check.
• Keybinding additions and small commands — see commands.rs for examples.
• Documentation — the book has user-facing docs that lag features.
• Bug fixes — many issues come with a reproducer; if not, asking on Matrix usually clarifies.

What every PR needs

From docs/CONTRIBUTING.md and the CI workflow at .github/workflows/build.yml:

1. Code compiles with cargo check.
2. cargo test --workspace and cargo integration-test pass.
3. cargo fmt --all --check and cargo clippy --workspace --all-targets -- -D warnings are clean.
4. cargo doc --no-deps --workspace --document-private-items builds without warnings.
5. cargo xtask query-check, cargo xtask theme-check, and cargo xtask docgen (followed by committing the generated changes) succeed.
6. Any new user-visible behaviour is documented in the book.
7. New commands are added to the static command list and the default keymap.

Communication

• Matrix space: #helix-community:matrix.org. The #helix-editor room is the primary chat.
• Issue tracker: github.com/helix-editor/helix/issues.
• The project's GitHub Wiki holds the FAQ and the Healthcheck guide.