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>
One needs to opt-in to this by specifying which file types should be
highlighted:
let g:markdown_github_languages = ['ruby', 'erb=eruby']
This may not work for all file types.
Closes#17.
