Add yaml metadata parsing

[cosmicexplorer]

Also add testing and allow multiple pandoc metadata blocks. Fix #66.

[syohex]

How about (or pos (point-min)) like other parts ?

[cosmicexplorer]

Fixed, not sure what I was thinking.

[syohex]

Thanks for great work. I put some comments, please check them.

[syohex]

Looks good. Could you squash commits ?

[cosmicexplorer]

Done.

[syohex]

And please remove following lines from commit messages, they makes no sense.

• Add defvar for markdown-search-until-condition
• Update with comments from @syohex

[cosmicexplorer]

Fixed.

[syohex]

Thanks 👍

[jrblevin]

Thanks for this patch. I only noticed one potential issue: YAML blocks inside fenced code blocks should be ignored:

```
---
title: foo
author: bar
---
```

You can use markdown-code-block-at-pos or markdown-code-block-at-point in the propertize function to skip code blocks.

[jrblevin]

Regarding my comment above about YAML in code blocks, I appended the test case and marked it with :expected-result :failed for now. See commit 90f3f59. I took a shot at fixing it, but it's more complicated than I thought. I think we also need to check for code blocks in markdown-get-match-boundaries, because of the separate matching functions.

[cosmicexplorer]

I'll take a look at these tomorrow. I think I can speed up the metadata block matching by propertizing metadata block start and end boundaries (the ---\n lines) and searching for characters with that property. We can then search for code block boundaries as well, using the same trick.

With respect to the if statements, I wanted to allow for local binding of the pandoc style; if you want to remove the if statements, I can factor that out into a separate function.

[vyp]

Thank you @cosmicexplorer for this! 👍

[cosmicexplorer]

Thinking about it a bit more, metadata would be invalid inside any other "block"-level construct, such as gfm code blocks or tilde blocks; I think that's it? All the other block constructs have some required characters at the beginning of each line. I think what would probably work would be to propertize all three "border" types (gfm blocks, pandoc tilde blocks, yaml metadata blocks) at once in a single pass, then figure out the appropriate context for any text enclosed within them by finding which if any characters with the syntax property for start/end blocks of those three block types are closest to the characters to propertize.

So basically, if our text is like:

... (some stuff without ~~~, ```, or ---)
`` ` (propertized as gfm-codeblock-begin by first block-construct pass)
--- (not propertized because already within block construct, but with markdown-inline-code-face)
key: value (look for enclosing block propertized text; found gfm-codeblock, so no propertizing/highlighting)
--- (not propertized)
`` ` (gfm-codeblock-end)

I'll try to do this, it seems not too hard.