tree-sitter-vimdoc

This grammar implements the vimdoc "spec" (ref1, ref2). Predictable results are the primary goal, so that output formats (e.g. HTML) are well-formed; the input (vimdoc) is secondary. The first step should always be to try to fix the input rather than insist on a grammar that handles vimdoc's endless quirks.

Overview

• block is the main top-level node, delimited by blank line(s) or any line starting with < (codeblock terminator).
  • Contains line and line_li nodes.
• line:
  • Contains atoms (words, tags, taglinks, …)
  • Contains headings (h1, h2, h3, column_heading) because codeblock terminated by "implicit stop" (no terminating <) consumes blank lines, so block has no way to end.
• line_li ("listitem")
  • Lines starting with -/•/[0-9]. (not +/*) are listitems.
  • Use the prefix node to detect if the listitem is ordered (numbered) or unodered.
  • Consumes lines until blank line, codeblock, or next listitem.
  • Nesting is ignored: indented listitems are parsed as siblings. Consumers can check leading whitespace to decide nesting.
• codeblock:
  • Contained by line or line_li, because ">" can start a codeblock at the end of any line.
  • Contains line nodes without word nodes: it's just the full raw text line including whitespace. This is somewhat dictated by its "preformatted" nature; parsing the contents would require loading a "child" language (injection). See #2.
  • The terminating < (and any following whitespace) is discarded (anonymous).
• url intentionally does not capture .,) at the end of the URL. See also Known issues.
• h1 = "Heading 1": ====== followed by text and optional *tags*.
• h2 = "Heading 2": ------ followed by text and optional *tags*.
• h3 = "Heading 3": UPPERCASE WORDS, followed by optional *tags*, followed by atoms.

Known issues