Most markdown implementations do not allow emphasis to span multiple
paragraphs. For example, commonmark.js, Markdown.pl, pandoc, and
Python-Markdown compile the following markdown
```markdown
*asdf
asdf*
```
to
```html
<p>*asdf</p>
<p>asdf*</p>
```
Some implementations compile it to
```html
<p><em>asdf</em></p>
<p>asdf*</p>
```
See https://johnmacfarlane.net/babelmark2/?normalize=1&text=*asdf%0A%0Aasdf*
Adding "^$" to :syn-end makes the emphasis end at an empty line like the
second compiled HTML above. While not perfect, it prevents an unmatched
`*` from emphasizing the entirety of the following text.
Many markdown implementations require that `*` be not followed (resp.
preceded) by whitespace to open (resp. close) emphasis. For example,
commonmark.js, Markdown.pl, and pandoc compile the follow markdown
```markdown
a* asdf *a
```
to
```html
<p>a* asdf *a</p>
```
On the other hand, Python-Markdown allows whitespace:
```html
<p>a<em> asdf </em>a</p>
```
See https://johnmacfarlane.net/babelmark2/?normalize=1&text=a*+asdf+*a
Since variants of commonmark (including GFM) are prevalent these days,
it makes more sense to follow the first behavior.
Syntax scripts for html and some other languages run :syn case ignore.
This may break syntax scripts of other fenced languages that implicitly
assume :syn case match.
This was reported to fix a folding issue I can't reproduce, and also
fixes some inconsistencies such as an underline style heading failing to
highlight until a redraw.
Resolves: https://github.com/tpope/vim-markdown/issues/179
If a line begins with a word that matches one of the languages listed in
`g:markdown_fenced_languages`, the line is wrongly detected as being the
start of a fenced code block for that language. This commit ensures that
a line is only treated as the start of fenced code block if the line
begins with three or more consecutive backtick or tilde characters (with
optional leading space characters).
Given that there are two separate syntax groups for code and code
blocks, it makes sense to have the triple-backtick/tilde fenced code
blocks be labeled as such.
Prior to this commit, _any_ line that started with at least 4 spaces or
a tab would be considered a code block.
For example, the third level of a 2-space-indented list would be
highlighted as code, not as list items.
Note: this conforms to the original Markdown spec:
> To produce a code block in Markdown, simply indent every line of the
> block by at least 4 spaces or 1 tab.
> A code block continues until it reaches a line that is not indented
> (or the end of the article).
While this doesn't explicitly state that a blank line _before_ the code
block is required, in practical testing, it is. As such, I've included
the requirement of a blank line preceeding the indent to match the
region start.
Any line not indented by at least 4 spaces will end the region.
Closes https://github.com/tpope/vim-markdown/issues/81
Closes https://github.com/tpope/vim-markdown/issues/164
Closes https://github.com/tpope/vim-markdown/issues/94 (possibly)
Closes https://github.com/tpope/vim-markdown/pull/140
The previous fenced code block matching did not support the syntax used
by [Kramdown][1] or fully support the syntax described in
[CommonMark][2]. The differences are:
* Kramdown requires \~ instead of \` in fences (CommonMark permits \~)
* Both permit code fences to have more than 3 \~ or \` characters
* Both require the closing fence to have as many chars as the opening
* Both permit the closing fence to have extra fence chars
* CommonMark explicitly forbids \` in the fence info string
This is likely the case with other Markdown variants, but these are the
only two that I have considered when authoring this commit.
This commit implements all of the above mentioned changes. The change
is mostly straight-forward. The only exception is that the end matching
is a little subtle since one of `\z2` and `\z3` will be empty, using the
more natural expression `\z2*\|\z3*` can hang the regex matcher. The
`\%(\z2\z3)*` expression is a bit less obvious but works reliably.
Note that I did not include any changes relating to the Pandoc syntax
mentioned in #65 and #74. If this syntax is desired, I can adjust this
commit to include it.
[1]: http://kramdown.gettalong.org/syntax.html#fenced-code-blocks
[2]: http://spec.commonmark.org/0.22/#code-fence
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
