Module batteries 

Battery registry: optional, feature-gated editor batteries (see it for the contract and checklist for adding new batteries). Battery registry: optional, feature-gated editor batteries.

Each battery is a self-contained language or behavior pack built only on the public core API (SyntaxHighlighter, EditorHook, HighlightTag, ConcealedLine, …) — the same surface external users get. Batteries emit only existing HighlightTag variants (never add new ones per battery) and never require twrite-gpui-side code; they wire up via set_highlighter / add_hook, as demonstrated by examples/vim.rs.

Adding a battery <name>

1. Create batteries/<name>.rs (promote to batteries/<name>/mod.rs when it outgrows one file) with a fixed template: Config (plain Clone data + Default), Highlighter (new + with_config), Hook (new + with_config). Hook-only batteries omit the highlighter.
2. Declare the feature in twrite-core/Cargo.toml (<name> = [...], with dep:<parser-crate> only if the battery needs a parser dependency).
3. Register the one-line path shim in super::lib (see markdown there): the public path stays twrite_core::<name> regardless of file layout.
4. Re-export from the twrite facade as twrite::<name> behind the same feature name, so users write twrite = { features = ["<name>"] }.
5. Add colocated unit tests in the battery module and an examples/<name>.rs demo (with required-features only if the demo needs the battery).