twrite_core/batteries/
mod.rs

1//! Battery registry: optional, feature-gated editor batteries.
2//!
3//! Each battery is a self-contained language or behavior pack built **only** on
4//! the public core API (`SyntaxHighlighter`, `EditorHook`, `HighlightTag`,
5//! `ConcealedLine`, …) — the same surface external users get. Batteries emit
6//! only existing `HighlightTag` variants (never add new ones per battery) and
7//! never require `twrite-gpui`-side code; they wire up via `set_highlighter` /
8//! `add_hook`, as demonstrated by `examples/vim.rs`.
9//!
10//! ## Adding a battery `<name>`
11//!
12//! 1. Create `batteries/<name>.rs` (promote to `batteries/<name>/mod.rs` when
13//!    it outgrows one file) with a fixed template: `Config` (plain `Clone`
14//!    data + `Default`), `Highlighter` (`new` + `with_config`), `Hook`
15//!    (`new` + `with_config`). Hook-only batteries omit the highlighter.
16//! 2. Declare the feature in `twrite-core/Cargo.toml` (`<name> = [...]`, with
17//!    `dep:<parser-crate>` only if the battery needs a parser dependency).
18//! 3. Register the one-line path shim in `super::lib` (see `markdown` there):
19//!    the public path stays `twrite_core::<name>` regardless of file layout.
20//! 4. Re-export from the `twrite` facade as `twrite::<name>` behind the same
21//!    feature name, so users write `twrite = { features = ["<name>"] }`.
22//! 5. Add colocated unit tests in the battery module and an `examples/<name>.rs`
23//!    demo (with `required-features` only if the demo needs the battery).
24//!
25//! <!-- New batteries are registered here as they land. -->
twrite_core/batteries/mod.rs

twrite_core/batteries/
mod.rs
