Lines Matching full:is
10 ## What is GitHub Flavored Markdown?
12 GitHub Flavored Markdown, often shortened as GFM, is the dialect of Markdown
13 that is currently supported for user content on GitHub.com and GitHub
19 GFM is a strict superset of CommonMark. All the features which are supported in
25 GFM is converted to HTML to ensure security and consistency of the website.
27 ## What is Markdown?
29 Markdown is a plain text format for writing structured documents,
45 syntaxes, which are often easier to write, is its readability.
48 > The overriding design goal for Markdown's formatting syntax is
49 > to make it as readable as possible. The idea is that a
50 > Markdown-formatted document should be publishable as-is, as
57 an equivalent sample of Markdown. Here is a sample of
76 This paragraph is part of the preceding list item.
78 a. This list is nested and does not require explicit item
81 This paragraph is part of the preceding list item.
89 And here is the equivalent in Markdown:
103 This paragraph is part of the preceding list item.
105 1. This list is nested and does not require explicit item continuation.
107 This paragraph is part of the preceding list item.
114 The AsciiDoc version is, arguably, easier to write. You don't need
115 to worry about indentation. But the Markdown version is much easier
116 to read. The nesting of list items is apparent to the eye in the
119 ## Why is a spec needed?
126 1. How much indentation is needed for a sublist? The spec says that
127 continuation paragraphs need to be indented four spaces, but is
128 not fully explicit about sublists. It is natural to think that
130 not require that. This is hardly a "corner case," and divergences
135 2. Is a blank line needed before a block quote or heading?
143 3. Is a blank line needed before an indented code block?
144 (`Markdown.pl` requires it, but this is not mentioned in the
152 4. What is the exact rule for determining when list items get
184 6. Is this one list with a thematic break in its second item,
205 For example, is the following a valid link, or does the code span
265 Because there is no unambiguous spec, implementations have diverged
282 Since this document describes how Markdown is to be parsed into
284 representation of the syntax tree instead of HTML. But HTML is capable
289 This document is generated from a text file, `spec.txt`, written
294 In the examples, the `→` character is used to represent tabs.
300 Any sequence of [characters] is a valid CommonMark
303 A [character](@) is a Unicode code point. Although some
312 A [line](@) is a sequence of zero or more [characters]
316 A [line ending](@) is a newline (`U+000A`), a carriage return
321 (`U+0020`) or tabs (`U+0009`), is called a [blank line](@).
325 A [whitespace character](@) is a space
329 [Whitespace](@) is a sequence of one or more [whitespace
332 A [Unicode whitespace character](@) is
337 [Unicode whitespace](@) is a sequence of one
340 A [space](@) is `U+0020`.
342 A [non-whitespace character](@) is any character
343 that is not a [whitespace character].
346 is `!`, `"`, `#`, `$`, `%`, `&`, `'`, `(`, `)`,
352 A [punctuation character](@) is an [ASCII
392 item is indented with a tab; this has exactly the same effect
423 optionally by a space, which is not considered part of the
424 content. In the following case `>` is followed by a tab,
425 which is treated as if it were expanded into three spaces.
426 Since one of these spaces is considered part of the
427 delimiter, `foo` is considered to be indented six spaces
509 of inline structure. So, for example, the following is a list with
604 Four spaces is too many:
679 It is required that all of the [non-whitespace characters] be the same.
680 So, this is not a thematic break:
723 this is a setext heading, not a paragraph followed by a thematic break:
779 as inline content. The heading level is equal to the number of `#`
801 More than six `#` characters is not a heading:
810 At least one space is required between the `#` characters and the
811 heading's contents, unless the heading is empty. Note that many
828 This is not a heading, because the first `#` is escaped:
846 Leading and trailing [whitespace] is ignored in parsing inline content:
887 A closing sequence of `#` characters is optional:
919 is not a closing sequence, but counts as part of the contents of the
1002 A [setext heading underline](@) is a sequence of
1006 The heading is a level 1 heading if `=` characters are used in
1014 setext heading comes after a paragraph, a blank line is needed between
1043 content as inlines. The heading's raw content is formed by
1090 Four spaces indent is too much:
1119 Four spaces is too much:
1223 A blank line is needed between a paragraph and a following
1237 But in general a blank line is not required before or after
1323 But there is no consensus about how to interpret
1408 An [indented code block](@) is composed of one or more
1410 An [indented chunk](@) is a sequence of non-blank lines,
1418 (A blank line is not needed, however, between a code block and a following
1431 If there is any ambiguity between an interpretation of indentation
1608 A [code fence](@) is a sequence
1615 following the code fence; this is trimmed of leading and trailing
1618 characters. (The reason for this restriction is that otherwise
1625 or tildes as the opening code fence. If the leading code fence is
1627 each line of the content (if present). (If a content line is not
1628 indented, it is preserved unchanged. If it is indented less than N
1629 spaces, all of the indentation is removed.)
1633 containing block (or document) is reached and no closing code fence
1637 event that a closing code fence is not found. But this makes parsing
1644 The content of a code fence is treated as literal text, not parsed
1645 as inlines. The first word of the [info string] is typically used to
1650 Here is a simple example with backticks:
1677 Fewer than three backticks is not enough:
1801 Fences can be indented. If the opening fence is indented,
1882 This is not a closing fence, because it is indented 4 spaces:
1955 the info string, the first word is typically used to specify
1956 the language of the code block. In HTML output, the language is
2034 An [HTML block](@) is a group of lines that is treated
2043 block, if no line is encountered that meets the [end condition]. If
2081 **End condition:** line is followed by a [blank line].
2087 **End condition:** line is followed by a [blank line].
2093 be ignored by the parser and passed through as-is, without changing
2117 In this case, the HTML block is terminated by the newline — the `**Hello**`
2123 (This restriction is intended to prevent unwanted interpretation
2189 as it is split where there would be whitespace:
2284 is actually part of the HTML block, which continues until a blank
2285 line or the end of the document is reached:
2300 To start an [HTML block] with a tag that is *not* in the
2350 The `<del>` tag is a nice example. We can surround content with
2352 HTML block, because the `<del>` tag is on a line by itself:
2384 the tag is not on a line by itself, we get inline HTML
2462 If there is no matching end tag, the block will end at the
2659 However, a following blank line is needed, except at the end of
2697 In some ways Gruber's rule is more restrictive than the one given
2708 There is one respect, however, in which Gruber's rule is more liberal
2711 First, it removes the need to parse balanced tags, which is
2713 if no matching end tag is found. Second, it provides a very simple
2746 more elegant way of achieving the same expressive power, which is also
2749 The main potential drawback is that one can no longer paste HTML
2806 deleted. The exception is inside `<pre>` tags, but as described
2818 title], which if it is present must be separated
2986 As noted in the section on [Links], matching of labels is
3007 Here is a link reference definition with no corresponding link.
3016 Here is another one:
3028 This is not a link reference definition, because there are
3038 This is a link reference definition, but it has no title:
3048 This is not a link reference definition, because it is indented
3062 This is not a link reference definition, because it occurs inside
3161 Whether something is a [link reference definition] is
3162 independent of whether the link reference it defines is
3179 is formed by concatenating the lines and removing initial and final
3287 is [tight] or [loose].
3309 GFM enables the `table` extension, where an additional leaf block type is
3312 A [table](@) is an arrangement of data with rows and columns, consisting of a
3317 parsed, separated by pipes (`|`). A leading and trailing pipe is also
3397 The table is broken at the first empty line, or beginning of another
3469 cells are inserted. If there are greater, the excess is ignored:
3497 If there are no rows in the body, no `<tbody>` is generated in HTML output:
3517 A [container block](#container-blocks) is a block that has other
3523 form of the definition is:
3525 > If X is a sequence of blocks, then the result of
3526 > transforming X in such-and-such a way is a container of type Y
3532 these constructions. (A recipe is provided below in the section entitled
3546 is a [block quote](#block-quotes) containing *Bs*.
3552 quote marker] is [paragraph continuation
3553 text] is a block quote with *Bs* as its content.
3554 [Paragraph continuation text](@) is text
3559 quotes] in a row unless there is a [blank line] between them.
3563 Here is a simple example:
3750 the `- bar` is indented too far to start a list, and can't
3752 interrupt paragraphs, so it is [paragraph continuation text].
3867 However, because of laziness, a blank line is needed between
3905 It is a consequence of the Laziness rule that any number
3964 A [list marker](@) is a
3968 is a `-`, `+`, or `*` character.
3971 is a sequence of 1--9 arabic digits (`0-9`), followed by either a
3973 limit is that with 10 digits we start seeing integer overflows
3979 blocks *Bs* starting with a [non-whitespace character], and *M* is a
3982 *Ls*, and indenting subsequent lines of *Ls* by *W + N* spaces, is a
3984 (bullet or ordered) is determined by the type of its list marker.
3985 If the list item is ordered, then it is also assigned a start
3991 a paragraph---that is, when it starts on a line that would
3994 the list item is ordered, the start number must be 1.
3995 2. If any line is a [thematic break][thematic breaks] then
3996 that line is not a list item.
4019 that the following is an ordered list item with start number 1,
4044 The most important thing to notice is that the position of
4046 is needed in subsequent blocks in the list item. If the list
4108 It is tempting to think of this in terms of columns: the continuation
4110 [non-whitespace character] after the list marker. However, that is not quite right.
4112 is needed. Which column this indentation reaches will depend on
4113 how the list item is embedded in other constructions, as shown by
4135 but is actually contained in the list item, because there is
4138 The converse is also possible. In the following example, the word `two`
4140 it is not considered part of the list item, because it is not indented
4159 Note that at least one space is needed between the list marker and
4290 block, and *M* is a list marker of width *W* followed by
4293 *Ls* by *W + 1* spaces, is a list item with *Bs* as its contents.
4294 If a line is empty, then it need not be indented. The type of the
4295 list item (bullet or ordered) is determined by the type of its list
4296 marker. If the list item is ordered, then it is also assigned a
4301 In the following case that is 6 spaces:
4318 And in this case it is 11 spaces:
4335 If the *first* block in the list item is an indented code block,
4373 Note that an additional space indent is interpreted as space
4425 This is not a significant restriction, because when a block begins
4447 one blank line, and *M* is a list marker of width *W*,
4449 indenting subsequent lines of *Ls* by *W + 1* spaces, is a list
4451 If a line is empty, then it need not be indented. The type of the
4452 list item (bullet or ordered) is determined by the type of its list
4453 marker. If the list item is ordered, then it is also assigned a
4495 In the following example, `foo` is not part of the list
4510 Here is an empty bullet list item:
4540 Here is an empty ordered list item:
4584 list item with the same contents and attributes. If a line is
4683 next [non-whitespace character] after the indentation is
4684 [paragraph continuation text] is a
4689 Here is an example with [lazy continuation lines]:
4763 6. **That's all.** Nothing that is not counted as a list item by rules
4797 One is not enough:
4814 Here we need four, because the list marker is wider:
4830 Three is not enough:
4922 the list marker, but this is not said), and that code under a list item
4925 example given has four spaces indentation. Although nothing is said
4926 about other kinds of block-level content, it is certainly reasonable to
4931 The four-space rule is clear and principled, and if the reference
4937 sublist needed three spaces. It is not surprising, then, that different
4945 is no way to give a spec for list items that will be guaranteed not
4949 in a way that is natural for a human to read.
4951 The strategy here is to let the width and indentation of the list marker
4959 This rule is superior, we claim, to any rule requiring a fixed level of
4960 indentation from the margin. The four-space rule is clear but
4961 unnatural. It is quite unintuitive that
4997 The choice of four spaces is arbitrary. It can be learned, but it is
5000 Would it help to adopt a two-space rule? The problem is that such
5002 initial list marker, allows text that is indented *less than* the
5044 This is extremely unintuitive.
5051 is not indented as far as the first paragraph `foo`:
5070 where the code is indented eight spaces. The spec above, by contrast, will
5071 parse this text as expected, since the code block's indentation is measured
5074 The one case that needs special treatment is a list item that *starts*
5075 with indented code. How much indentation is required in that case, since
5086 GFM enables the `tasklist` extension, where an additional processing step is
5089 A [task list item](@) is a [list item][list items] where the first block in it
5090 is a paragraph which begins with a [task list item marker] and at least one
5097 When rendered, the [task list item marker] is replaced with a semantic checkbox element;
5100 If the character between the brackets is a whitespace character, the checkbox
5101 is unchecked. Otherwise, the checkbox is checked.
5141 A [list](@) is a sequence of one or more
5152 A list is an [ordered list](@)
5159 of an [ordered list] is determined by the list number of
5163 A list is [loose](@) if any of its constituent
5166 between them. Otherwise a list is [tight](@).
5167 (The difference in HTML output is that paragraphs in a loose list are
5202 In CommonMark, a list can interrupt a paragraph. That is,
5203 no blank line is needed to separate a paragraph from a following
5222 The number of windows in my house is
5223 14. The number of doors is 6.
5231 two reasons. First, it is natural and not uncommon for people
5258 is a list item containing a paragraph followed by a nested sublist,
5259 as all Markdown implementations agree it is (though the paragraph
5260 may be rendered without `<p>` tags, since the list is "tight"),
5272 Since it is well established Markdown practice to allow lists to
5284 The number of windows in my house is
5285 14. The number of doors is 6.
5287 <p>The number of windows in my house is
5288 14. The number of doors is 6.</p>
5294 The number of windows in my house is
5295 1. The number of doors is 6.
5297 <p>The number of windows in my house is</p>
5299 <li>The number of doors is 6.</li>
5407 since none is indented enough to belong to the previous list
5452 three spaces. Here `- e` is treated as a paragraph continuation
5453 line, because it is indented more than three spaces:
5471 And here, `3. c` is treated as in indented code block,
5472 because it is indented four spaces and preceded by a
5495 This is a loose list, because there is a blank line between
5518 So is this, with a empty second item:
5538 These are loose lists, even though there is no space between the items,
5585 This is a tight list, because the blank lines are in a code block:
5609 This is a tight list, because the blank line is between two
5610 paragraphs of a sublist. So the sublist is loose while
5611 the outer list is tight:
5634 This is a tight list, because the blank line is inside the
5654 This list is tight, because the consecutive block elements
5678 A single-paragraph list is tight:
5703 This list is loose, because of the blank line between the
5723 Here the outer list is loose, the inner list tight:
5783 `hi` is parsed as code, leaving the backtick at the end as a literal
5834 If a backslash is itself escaped, the following character is not:
5843 A backslash at the end of the line is a [hard line break]:
5949 is used as an authoritative source for the valid entity
5966 numeric character reference is parsed as the corresponding
6130 is a string of one or more backtick characters (`` ` ``) that is neither
6141 characters, a single [space] character is removed from the
6146 This is a simple code span:
6175 Note that only *one* space is stripped:
6183 The stripping only happens if the space is on both
6243 when rendering `<code>` elements, so it is recommended that
6277 constructs except HTML tags and autolinks. Thus, for example, this is
6278 not parsed as emphasized text, since the second `*` is part of a code
6288 And this is not parsed as a link:
6298 Thus, this is code:
6307 But this is an HTML tag:
6316 And this is code:
6325 But this is an autolink:
6334 When a backtick string is not closed by a matching backtick string,
6370 This is enough for most users, but these rules leave much undecided,
6385 is clear and they are useful (especially in contexts like bibliography
6395 internal underscores. (It is best practice to put these in code
6406 First, some definitions. A [delimiter run](@) is either
6407 a sequence of one or more `*` characters that is not preceded or
6409 of one or more `_` characters that is not preceded or followed by
6412 A [left-flanking delimiter run](@) is
6413 a [delimiter run] that is (1) not followed by [Unicode whitespace],
6420 A [right-flanking delimiter run](@) is
6421 a [delimiter run] that is (1) not preceded by [Unicode whitespace],
6473 iff (if and only if) it is part of a [left-flanking delimiter run].
6476 it is part of a [left-flanking delimiter run]
6482 iff it is part of a [right-flanking delimiter run].
6485 it is part of a [right-flanking delimiter run]
6491 iff it is part of a [left-flanking delimiter run].
6494 it is part of a [left-flanking delimiter run]
6500 iff it is part of a [right-flanking delimiter run].
6503 it is part of a [right-flanking delimiter run]
6531 is backslash-escaped.
6535 is backslash-escaped.
6541 an interpretation `<strong>...</strong>` is always preferred to
6544 14. An interpretation `<em><strong>...</strong></em>` is always
6550 `*foo _bar* baz_` is parsed as `<em>foo _bar</em> baz_` rather
6556 `**foo **bar baz**` is parsed as `**foo <strong>bar baz</strong>`
6560 than emphasis. So, when there is a choice between an interpretation
6562 former always wins. Thus, for example, `*[foo*](bar)` is
6577 This is not emphasis, because the opening `*` is followed by
6587 This is not emphasis, because the opening `*` is preceded
6607 Intraword emphasis with `*` is permitted:
6632 This is not emphasis, because the opening `_` is followed by
6642 This is not emphasis, because the opening `_` is preceded
6652 Emphasis with `_` is not allowed inside words:
6676 is right-flanking and the second left-flanking:
6685 This is emphasis, even though the opening delimiter is
6686 both left- and right-flanking, because it is preceded by
6698 This is not emphasis, because the closing delimiter does
6708 This is not emphasis, because the closing `*` is preceded by
6729 This is not emphasis, because the second `*` is
6731 (hence it is not part of a [right-flanking delimiter run]:
6740 The point of this restriction is more easily appreciated
6750 Intraword emphasis with `*` is allowed:
6762 This is not emphasis, because the closing `_` is preceded by
6772 This is not emphasis, because the second `_` is
6782 This is emphasis within emphasis:
6791 Intraword emphasis is disallowed for `_`:
6814 This is emphasis, even though the closing delimiter is
6815 both left- and right-flanking, because it is followed by
6834 This is not strong emphasis, because the opening delimiter is
6844 This is not strong emphasis, because the opening `**` is preceded
6855 Intraword strong emphasis with `**` is permitted:
6873 This is not strong emphasis, because the opening delimiter is
6893 This is not strong emphasis, because the opening `__` is preceded
6903 Intraword strong emphasis is forbidden with `__`:
6933 This is strong emphasis, even though the opening delimiter is
6934 both left- and right-flanking, because it is preceded by
6947 This is not strong emphasis, because the closing delimiter is preceded
6960 This is not strong emphasis, because the second `**` is
6970 The point of this restriction is more easily appreciated
7007 This is not strong emphasis, because the closing delimiter is
7017 This is not strong emphasis, because the second `__` is
7027 The point of this restriction is more easily appreciated
7037 Intraword strong emphasis is forbidden with `__`:
7060 This is strong emphasis, even though the closing delimiter is
7061 both left- and right-flanking, because it is followed by
7142 is precluded by the condition that a delimiter that
7146 closing delimiters is a multiple of 3 unless
7223 ** is not an empty emphasis
7225 <p>** is not an empty emphasis</p>
7230 **** is not an empty strong emphasis
7232 <p>**** is not an empty strong emphasis</p>
7338 __ is not an empty emphasis
7340 <p>__ is not an empty emphasis</p>
7345 ____ is not an empty strong emphasis
7347 <p>____ is not an empty strong emphasis</p>
7564 However, strong emphasis within strong emphasis is possible without
7709 GFM enables the `strikethrough` extension, where an additional emphasis type is
7712 Strikethrough text is any text wrapped in two tildes (`~`).
7737 (the URI that is the link destination), and optionally a [link title].
7749 other, the inner-most definition is used.
7759 is part of a code span.
7762 [emphasis and strong emphasis]. Thus, for example, `*[foo*](url)` is a link.
7781 characters (`"`), including a `"` character only if it is
7785 characters (`'`), including a `'` character only if it is
7789 (`(...)`), including a `(` or `)` character only if it is
7807 Here is a simple inline link:
7840 The destination can only contain spaces if it is
7874 The destination can contain `)` if it is enclosed
7892 is not matched properly:
7963 Note that a backslash before a non-escapable character is
8042 But it is easy to work around this by using a different quote type:
8053 But it is hard to see a good rationale for the extra complexity this
8066 [Whitespace] is allowed around the destination and title:
8076 But it is not allowed between the link text and the
8216 with the first right bracket (`]`) that is not backslash-escaped.
8230 document is used. (It is desirable in such cases to emit a warning.)
8236 Here is a simple example:
8365 Matching is case-insensitive:
8376 Unicode case fold is used:
8379 [Толпой][Толпой] is a Russian word.
8383 <p><a href="/url">Толпой</a> is a Russian word.</p>
8387 Consecutive internal [whitespace] is treated as one space for
8400 No [whitespace] is allowed between the [link text] and the
8423 This is a departure from John Gruber's original Markdown syntax
8429 [shortcut reference links]. If whitespace is allowed between the
8445 links, it is harmless to allow space between the link text and
8446 link label; but once shortcut references are introduced, it is
8451 the first is used:
8464 Note that matching is performed on normalized strings, not parsed
8519 Note that in this example `]` is not backslash-escaped:
8563 `[foo][]` is equivalent to `[foo][foo]`.
8595 As with full reference links, [whitespace] is not
8612 document and is not followed by `[]` or a link label.
8616 Thus, `[foo]` is equivalent to `[foo][]`.
8688 Note that this is a link, because a link label ends with the first
8738 In the following case `[bar][baz]` is parsed as a reference,
8750 Here, though, `[foo][bar]` is parsed as a reference, since
8751 `[bar]` is defined:
8763 Here `[foo]` is not parsed as a shortcut reference, because it
8764 is followed by a link label (even though `[bar]` is not defined):
8779 Syntax for images is like the syntax for links, with one
8786 as its contents. When an image is rendered to HTML,
8787 this is standardly used as the image's `alt` attribute.
8819 Though this spec is concerned with parsing, not rendering, it is
8822 the above example, the alt attribute's value is `foo bar`, not `foo
8824 content is rendered, without formatting.
8923 As with reference links, [whitespace] is not allowed
9011 [absolute URI] followed by `>`. It is parsed as
9021 For purposes of this spec, a [scheme](@) is any sequence
9049 Uppercase is also fine:
9111 followed by `>`. The link's label is the email address,
9112 and the URL is `mailto:` followed by the email address.
9115 for these purposes, is anything that matches
9204 when the text `www.` is found followed by a [valid domain].
9243 of parentheses. If there is a greater number of closing parentheses than
9262 This check is only done when the link ends in a closing parentheses `)`, so if
9273 resemble an [entity reference][entity references]; if the preceding text is `&`
9274 followed by one or more alphanumeric characters. If so, it is excluded from
9304 Anonymous FTP is available at ftp://foo.bar.baz.
9308 <p>Anonymous FTP is available at <a href="ftp://foo.bar.baz">ftp://foo.bar.baz</a>.</p>
9312 An [extended email autolink](@) will be recognised when an email address is
9334 hello@mail+xyz.example isn't valid, but hello+xyz@mail.example is.
9336 …example isn't valid, but <a href="mailto:hello+xyz@mail.example">hello+xyz@mail.example</a> is.</p>
9362 Text between `<` and `>` that looks like an HTML tag is parsed as a
9367 Here is the grammar for tags:
9379 letters, digits, `_`, `.`, `:`, or `-`. (Note: This is the XML
9380 specification restricted to ASCII. HTML5 is laxer.)
9392 is a nonempty string of characters not
9450 [Whitespace] is allowed:
9553 foo <!-- this is a --
9556 <p>foo <!-- this is a --
9640 Filtering is done by replacing the leading `<` with the entity `<`. These
9641 tags are chosen in particular as they change how HTML is interpreted in a way
9642 unique to them (i.e. nested HTML is interpreted differently), and this is
9651 <xmp> is disallowed. <XMP> is also disallowed.
9656 <xmp> is disallowed. <XMP> is also disallowed.
9664 A line break (not in a code span or HTML tag) that is preceded
9666 is parsed as a [hard line break](@) (rendered
9814 A regular line break (not in a code span or HTML tag) that is not
9815 preceded by two or more spaces or a backslash is parsed as a
9888 list items, and so on---is constructed. Text is assigned to these
9890 map of links is constructed.
9897 At each point in processing, the document is represented as a tree of
9898 **blocks**. The root of the tree is a `document` block. The `document`
9901 is normally considered **open**, meaning that subsequent lines of input
9903 Here, for example, is a possible document tree, with the open blocks
9922 Each line that is processed has an effect on this tree. The line is
9940 if the block is to remain open. For example, a block quote requires a
9954 This is text that can be incorporated into the last open
9958 that is a [setext heading underline].
9960 Reference link definitions are detected when a paragraph is closed;
9965 We can see how this works by considering how the tree above is
9975 At the outset, our document model is just
9989 the `block_quote`. Then the text is added to the last open
10005 is a "lazy continuation" of the open `paragraph`, so it gets added
10022 opened as a child of the `block_quote`. A `list_item` is also
10024 the `list_item`. The text is then added to the new `paragraph`:
10045 is added as a child of the new `list_item`, to contain the text.
10095 By far the trickiest part of inline parsing is handling emphasis,
10096 strong emphasis, links, and images. This is done using the following
10107 The [delimiter stack] is a doubly linked list. Each
10112 - whether the delimiter is "active" (all are active to start), and
10113 - whether the delimiter is a potential opener, a potential closer,
10157 descend in the [delimiter stack]. If it is NULL, we can
10163 is NULL).
10181 - If one is found:
10196 of the delimiter stack. If the closing node is removed, reset
10199 - If none is found:
10205 + If the closer at `current_position` is not a potential opener,