Both the original spec on Daring Fireball and the more rigorous
CommonMark spec state that a tab at the beginning of the line is
synonymous with 4 spaces. For the record, I think this was a mistake,
but if you can't beat 'em, join 'em.
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
Previously in Markdown files, Vim would treat heading syntax in code
fences as Markdown headers. This commit ensures that only headers will
be folded by checking the 'synIDattr' of the item.
E.g. The comment in this code snippet would have been treated as a
Markdown header.
```sh
# This is a comment
echo "Hello world"
```
