Module indent 

Where should this line start?

The indent engine, beside its peers: crate::text_objects and crate::motions are the same shape – computation over the parse tree, driven by .scm files this crate already owns. IN.2 adds the indents.scm query evaluator here; IN.1 ships the lexical half below, which is what runs when no tree is available.

Pure and synchronous by construction – no I/O, no async, no host state – because every consumer sits on the keystroke path (docs/dev/architecture/auto-indent.md §2).

The [IndentUnit] value itself lives in lattice-core, not here: the > / < operators in lattice-grammar consume it, and this crate depends on lattice-grammar, so owning it here would be a cycle.

Two policies over one mechanism

• [IndentMethod::Keep] – copy the previous non-blank line’s indent. Vim’s autoindent. No scan, no cleverness.
• [IndentMethod::Syntax]’s fallback – the copy, plus one level if the previous line leaves a bracket unclosed, minus one if the target line opens with a closer. Vim’s smartindent, roughly.

Vim keeps these separate for a reason worth preserving: the bracket rule misfires in a language where { is not a block opener, and keep is what a user picks when they want the dumbest predictable thing. Rather than special-casing that, the bracket sets are per-language and languages with no bracket notion (plain text, markdown) have empty sets – at which point the bridge degrades to keep on its own.

What this deliberately does not do

The scan is lexical, so it cannot tell a brace in code from a brace in a string or a comment. println!("{") counts as an opener here. That is a known and accepted wrong answer: the whole point of this half is to be the thing that still works when no parse tree is available, and a scan sophisticated enough to track string state per-language would be a worse, slower duplicate of what IN.2’s tree-sitter path does properly. When the tree is available, syntax uses it and never reaches here.

Structs

BracketSyntax

Per-language bracket sets for the opener/closer scan.

Functions

electric_columns

The indent, in columns, for a line being electrically re-indented.

indent_columns_for_new_line

indent_for_new_line in display columns, before rendering. Separate so IN.2’s engine can compare its own answer against the fallback’s without allocating.

indent_for_new_line

The whitespace a newly created line should start with.

is_electric_trigger

Whether typing typed at the end of line_head should re-indent the current line.

tree_levels_for_line

Indent level, in steps, for the existing line row.

tree_levels_for_new_line

Indent level, in steps, for a new line inserted at byte at.