Formally specify the @ extension annotations in ABNF output #2
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
tree-sitter2abnf emits ABNF with non-standard
@annotations (@token,@pattern,@prec,@field,@grammar,@extras) to represent tree-sitter concepts that have no ABNF equivalent.These extensions are documented narratively in plain-text-accounting-formats/docs/abnf-variants.md, but they lack a formal grammar definition.
Why this matters
The development loop is: tree-sitter grammar → tree-sitter2abnf → ABNF text → tree-sitter ABNF parser → syntax highlighting. Currently the generated ABNF cannot be parsed by the tree-sitter ABNF grammar because the
@extensions are not part of the grammar. This breaks the feedback loop — highlighting silently produces nothing, and broken output goes unnoticed.Without a formal spec, no parser (tree-sitter or otherwise) can be built to handle the extended syntax.
Requested
@extension syntax formally (as ABNF rules or similar) — what is legal, how annotations nest, where they can appeardocs/extensions.abnfor in the README)Migrated from Codeberg: originally #2, opened 2026-03-18.
The formal specification of
@extensions is moving to a dedicated repo: hum3/yabnf.Audit completed: all 16 extensions (7 grammar-level directives, 9 rule-level annotations) confirmed load-bearing against real tree-sitter grammars (json, javascript). No redundant extensions found.
Gap identified: tree-sitter's top-level
precedenceskey has no@directive yet — to be addressed in the YABNF spec.The formal spec is tracked in yabnf#1. This issue becomes "adopt YABNF as optional output format" once the spec is ready.
Keeping open, blocked on yabnf spec.
(hum3, 2026-03-18)