Fix indented code block detection and fenced code block categorization

[zhimsel]

Please see individual commit messages for more detailed notes.

Happy to address any feedback and RFCs.

Closes #81 Closes #164 Closes #94 (possibly) Closes #140

[j-hui]

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.

I'm not sure this is always the case. One can leave blank lines between entries in a list, and one may also have multi-paragraph list items. For instance, in this 4-space indented list:

-   Parent paragraph 1

    Parent paragraph 2*

    -   Child paragraph 1

        Child paragraph 2*

            Child code block*

    Parent 1 paragraph 3*

        Parent code block*

I used * to mark all lines that follow a blank line and start with 4 spaces followed by a non-list marker. The above code is rendered like this:

• Parent paragraph 1

  Parent paragraph 2*

  • Child paragraph 1

    Child paragraph 2*

    Child code block*

  Parent 1 paragraph 3*

  Parent code block*

---

The same is true when you consider 2-space indented lists:

- Parent paragraph 1

  Parent paragraph 2

  - Child paragraph 1

    Child paragraph 2*

        Child code block*

  Parent 1 paragraph 3

      Parent code block*

Rendered like this:

• Parent paragraph 1

  Parent paragraph 2

  • Child paragraph 1

  Child paragraph 2*

  Child code block*

  Parent 1 paragraph 3

  Parent code block*

---

[tpope]

@j-hui if I understand you correctly, you are pointing out that fix misses some cases, and not that it breaks anything that wasn't automatically broken. If so, this is helpful to know, but not a deal breaker for merging.

On that I note, I am especially loathe to merge any vim-markdown PR without fully vetting it, because the potential for regressions is so damn high, but given that this is literally a one line change, I feel confident I fully understand it and am willing to merge. @zhimsel Can you ditch the "last changed at" update? I only update that line when submitting upstream to appease Bram. Changing it in every commit makes commands like git revert a nightmare to use.

[j-hui]

@tpope yeah, I don't think this will break anything not alrready broken, i.e., it won't highlight anything not already highlighted as a code block.

[zhimsel]

Can you ditch the "last changed at" update?

Sure thing!

I only update that line when submitting upstream to appease Bram. Changing it in every commit makes commands like git revert a nightmare to use.

Ha, understandable.