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"
```
Addresses an issue metioned in tpope/vim-markdown#10 of adding a
foldtext function.
- Displays == and -- headers as # and ##
- Use markdown header style instead of '+--' to show nesting
Given the example of
This is Header One
==================
This is Header Two
-----------------
### This is Header Three
This is a normal line
Instead of:
+-- 6 lines: This is Header One-----------------------------
+--- 4 lines: This is Header Two----------------------------
+---- 2 lines: ### This is Header Three---------------------
You get:
# This is Header One [6 lines]-------------------------------
## This is Header Two [4 lines]------------------------------
### This is Header Three [2 lines]----------------------------
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>
