Unnecessary limit to list indent depth

[rdeforest]

On lines 64 and 65 of syntax.vim (as of commit 63074a5), the number of spaces is 0 to 4:

syn match markdownListMarker "\%(\t\| \{0,4\}\)[-*+]\%(\s\+\S\)\@=" contained

Is there a reason to include a maximum number of spaces instead of using "{0,}" or the more common '*' to indicate zero or more spaces? Is this related to the four-space indent for monospace text blocks? (I've switched to plasticboy's plugin in the short term rather than digging into this myself.)

Unrelated to that, but not worthy of its own issue, line four of the comment header is not strictly accurate:

" Last Change:  2013 May 30

Either automatically update it with some git scripting magic or remove the line entirely.

[tpope]

Yes, it's a compromise with code blocks. Triply nested lists are extremely rare (as in I've never seen one in the wild), but I'd entertain extending it to 8 spaces if it's an issue.

The header is only there to appease Bram upstream. If Git magic like that really exists I want no part in it.

[rdeforest]

Wow, that was probably the fastest response I've ever seen on a github issue. Nice!

When I have unlimited indent spaces I use two space indents and start indented, but I switched to one space and starting with zero when I switched to your plugin. Then I had a topic (a train of thought log) which demanded more:

- Log entry context
 - Title of thought(s)
  - Analysis of thought
   - Description of abstract subject
    - Part 1 of description
    - Part 2 of description
   - "Example Subject 1: My previous team"
    - Specifics of the example
     - Part 1 of the specifics
      - First subset of part 1 of specifics
       - First member of first subset of part 1 of specifics

And so on. This example may be a bit weird because I had to de-personalize it, but hopefully it's clear what the use case is, why anyone would want it and all that.

In the interest of finding out what other parsers do, I tried the above in this comment without spaces and a) it rounded odd-spaced indents up, so I converted back to two-space indent and then b) it handled my 8-fold indent without any trouble:

• Log entry context
  • Title of thought(s)
    • Analysis of thought
      • Description of abstract subject
        • Part 1 of description
        • Part 2 of description
      • "Example Subject 1: My previous team"
        • Specifics of the example
          • Part 1 of the specifics
            • First subset of part 1 of specifics
              • First member of first subset of part 1 of specifics

So that's at least two parsers (the other being Ben's) which handle at least 16 spaces gracefully, for whatever that's worth.

With all of that written, I could also make an argument that what I'm trying to do with markdown is a Bad Idea in a certain sense and I'd be better off switching to YAML, JSON, CoffeeScript or maybe even my own DSL for managing my admittedly unhelpfully convoluted thoughts. I would take no offense were you to close this issue without further action.

Also, heh, Bram is a mad genius. I agree with your approach: "oh, ok. I'll just put something in there then... Sorry to trouble you sir!" :)

Thanks again for the quick response and for all your voluntary work on this plugin I've made heavy use of over the last few months and may come back to when Ben's turns out to have some blemish I don't know about yet.

[rdeforest]

I meant also to mention in case it wasn't adequately implied: my real use case is actually much longer.

[MonkeyIsNull]

I ran into this today ... taking notes in a meeting (yeah, it's the only way I can stay awake :/ ) -- gave me a little start when the colors went away. Bumping to 8 would be awesome, changed it locally and it seemed like it didn't give me any problems.

[hardkrash]

I bumped mine to 32, I have 4 space indents and often have lists 4 to 5 deep.

[michaelcoyote]

I'm going to bump this. I often go to 3 levels deep and sometimes even 4. It might be good as a configurable variable.

[rdeforest]

As the four space limitation exists because of code blocks, could code blocks be made to require surrounding lines matching /^($|```)/?

That is:

- item
      - item

    - code

  - item

Since this is a syntax highlighting plugin I'm figuring backwards compatibility isn't a concern.

[tpope]

The triple backtick syntax is nonstandard (and kinda gross and ugly imho). But the blank line compromise might be serviceable, although I'm not sure how feasible it would be to layer on top of everything else.

[lucy]

#167 incorrectly closes this. There's still a list indent limit of 4 spaces.