This is an incremental Markdown (CommonMark
with support for extension) parser that integrates well with the
Lezer parser system. It does not in
fact use the Lezer runtime (that runs LR parsers, and Markdown can't
really be parsed that way), but it produces Lezer-style compact syntax
trees and consumes fragments of such trees for its incremental
parsing.
Note that this only parses the document, producing a data structure
that represents its syntactic form, and doesn't help with outputting
HTML. Also, in order to be single-pass and incremental, it doesn't do
some things that a conforming CommonMark parser is expected to
do—specifically, it doesn't validate link references, so it'll parse
[a][b] and similar as a link, even if no [b] reference is
declared.
The
@codemirror/lang-markdown
package integrates this parser with CodeMirror to provide Markdown
editor support.
When provided, this will be used to parse the content of code
blocks. info is the string after the opening ``` marker,
or the empty string if there is no such info or this is an
indented code block. If there is a parser available for the
code, it should return a function that can construct the
parse.
If this is a composite block, this should hold a function that,
at the start of a new line where that block is active, checks
whether the composite block should continue (return value) and
optionally adjusts the line's base position
and registers nodes for any markers involved
in the block's syntax.
Add highlighting tag information for this node. The value of
this property may either by a tag or array of tags to assign
directly to this node, or an object in the style of
styleTags's
argument to assign more complicated rules.
Move to the next input line. This should only be called by
(non-composite) block parsers that consume
the line directly, or leaf block parser
nextLine methods when they
consume the current line (and return true).
Add a block element from a leaf parser. This
makes sure any extra composite block markup (such as blockquote
markers) inside the block are also added to the syntax tree.
Block parsers handle block-level structure. There are three
general types of block parsers:
Composite block parsers, which handle things like lists and
blockquotes. These define a parse method
that starts a composite block
and returns null when it recognizes its syntax.
Eager leaf block parsers, used for things like code or HTML
blocks. These can unambiguously recognize their content from its
first line. They define a parse method
that, if it recognizes the construct,
moves the current line forward to the
line beyond the end of the block,
add a syntax node for the block, and
return true.
Leaf block parsers that observe a paragraph-like construct as it
comes in, and optionally decide to handle it at some point. This
is used for "setext" (underlined) headings and link references.
These define a leaf method that checks
the first line of the block and returns a
LeafBlockParser object if it wants to
observe that block.
The eager parse function, which can look at the block's first
line and return false to do nothing, true if it has parsed
(and moved past a block), or null if
it has started a composite block.
A leaf parse function. If no regular parse
functions match for a given line, its content will be
accumulated for a paragraph-style block. This method can return
an object that overrides that style of
parsing in some situations.
Some constructs, such as code blocks or newly started
blockquotes, can interrupt paragraphs even without a blank line.
If your construct can do this, provide a predicate here that
recognizes lines that should end a paragraph (or other non-eager
leaf block).
When given, this parser will be installed directly before the
block parser with the given name. The default configuration
defines block parsers with names LinkReference, IndentedCode,
FencedCode, Blockquote, HorizontalRule, BulletList, OrderedList,
ATXHeading, HTMLBlock, and SetextHeading.
Update the parser's state for the next line, and optionally
finish the block. This is not called for the first line (the
object is contructed at that line), but for any further lines.
When it returns true, the block is finished. It is okay for
the function to consume the current
line or any subsequent lines when returning true.
Called when the block is finished by external circumstances
(such as a blank line or the start of
another construct). If this parser can handle the block up to
its current position, it should
finish the block and return
true.
Add a delimiter at this given position. open
and close indicate whether this delimiter is opening, closing,
or both. Returns the end of the delimiter, for convenient
returning from parse functions.
Remove all inline elements and delimiters starting from the
given index (which you should get from
findOpeningDelimiter,
resolve delimiters inside of them, and return them as an array
of elements.
The parse function. Gets the next character and its position as
arguments. Should return -1 if it doesn't handle the character,
or add some element or
delimiter and return the end
position of the content it parsed if it can.
When given, this parser will be installed directly before the
parser with the given name. The default configuration defines
inline parsers with names Escape, Entity, InlineCode, HTMLTag,
Emphasis, HardBreak, Link, and Image. When no before or
after property is given, the parser is added to the end of the
list.
Delimiters are used during inline parsing to store the positions
of things that might be delimiters, if another matching
delimiter is found. They are identified by objects with these
properties.
If this is given, the delimiter should be matched automatically
when a piece of inline content is finished. Such delimiters will
be matched with delimiters of the same type according to their
open and close properties. When a
match is found, the content between the delimiters is wrapped in
a node whose name is given by the value of this property.
请发表评论