Blockquote Issues

[mmbradle]

Issue 1: No blockquote without newline

Code

# Item 1
# Item 2
    Block Quote Text
# Item 3

Result

1. Item 1
2. Item 2 Block Quote
3. Item 3

The documentation for 2.1 claims: Text started with 4 or more spaces is a blockquote
This doesn't seem true in this case. Perhaps this is merely a documentation bug. However, the newline is awkward anyway, so it would be nice if this would work

Issue 2: BlockQuote restarts list numbering

Code

# Item 1
# Item 2

    Block Quote Text
# Item 3

Result

1. Item 1
2. Item 2 
    Block Quote
1. Item 3

Item 3 should be number 3, but it shows up as number 1

Issue 3: BlockQuote at multiple list levels

GitHub style markdown allows for the following:

1. Outer Item 1
    1. Inner Item 1
        > quote 1
    1. Inner Item 2
2. Outer Item 2
> quote 2

Quote 1 and quote 2 show up at different levels. I cannot seem to achieve the same with vimwiki markdown

Issue 4: No nested BlockQuotes

In GitHub style markdown this is achievable like this:

> This is the first level of quoting.
>
> > This is nested blockquote.
>
> Back to the first level.

It seems like this is a deficiency with not having a delimiting character dedicated to block quotes.

Issue 5: Newlines in blockquotes are not honored

    Block quote line 1 
    Block quote line 2

This all shows up on one line.

Note: The desired result is achievable with:

    Block quote line 1<br> 
    Block quote line 2

---

PS Thank you for vimwiki. It is a fantastic tool.

[EinfachToll]

Regarding Issue 3: what do you mean by

Quote 1 and quote 2 show up at different levels. I cannot seem to achieve the same with vimwiki markdown

? In Github, the quotes are not rendered as quotes. And Vimwiki has no conversion from Markdown to HTML.

Apart from that, your points are valid and I agree that we need a dedicated syntax element for quotes (and then, of course, fix the current behavior).
A line starting with > is the obvious solution, but there are different flavors. The official Markdown syntax also allows for paragraphs like this:

> a blockquote
continuation of quote

no blockquote

Pandoc markdown requires that there is one empty line above a blockquote in order to avoid confusion with text where a line accidentially starts with a >.
Feel free to express your opinions, @mmbradle and everyone else reading this.

[mmbradle]

Regarding issue #3, I think I see the misunderstanding. I had used the Dillinger editor located at http://dillinger.io/ to perform my tests for this. This editor seems to work differently for this case than the GitHub editor does. Even though the Dillinger editor claims to be in GitHub mode.

If the newline is required like in Pandoc, how will you know whether the blockquote is contained in a list or breaking the list. It seems like the newline is significant for other reasons and then you might need to double up newlines to express certain things.

The syntax I'm seeing here: http://daringfireball.net/projects/markdown/syntax#blockquote seems to do just about everything that I would need, but I'm not sure if you would want to support the optional things (such as your example).

[EinfachToll]

If the newline is required like in Pandoc, how will you know whether the blockquote is contained in a list or breaking the list.

Every element that is more indented than the list item above it is inside the list, everything else breaks the list.
In the same manner we could define blockquotes like this:

- list item
  > quote start
    quote continued
  not quote, but still inside list
- next list item
list end

Pro: the user is forced to format the text so that it looks good in ASCII version as well as in HTML. Cons: it's yet another variant in the already chaotic world of markup languages the user has to be aware of.

[mmbradle]

I see your points, and I'm not sure which is better. My knee-jerk reaction would be to aim at the variant of Markdown defined at daringfireball. Perhaps I would add the '>' on every line variant first and eventually add the option to be able to add the '>' on only the first line. Although that second option bothers me as a developer as I don't like what I'm imagining the grammar would be to express such an option. It doesn't seem tidy to me.

For myself (as a user), I don't need the additional line stuff. I keep blockquotes on one line in vimwiki and turn on wrap if I need to see everything at once. More often I'll just generate the webpage and view the quote there and set nowrap By in large I'm doing outlines of my lecture notes, and so keeping things on one line lets me move stuff around easily. I realize that is a very specific use-case, but perhaps having a use-case is helpful to you. On a related note to that use-case, I do like to be able to put several quotes in a row by several sources, so I'd like to be able to delineate between quotes somehow. The programmer in me says that there should be an end tag at the end of a block quote, even though that is non-standard. Otherwise a blank line between two quotes will be needed, which I suppose would be fine and probably closer conform to the standards of what others are doing.

[tinmarino]

Fixed by last commit: (issue 2 and 5)

2. OK BlockQuote restarts list numbering

3. OK Newlines in blockquotes are not honored

   • Fixed: see the tests

4. NO No blockquote without newline

   • Same behavior as pandoc/markdown => This is normal

5. NO No nested BlockQuotes

6. NO BlockQuote at multiple list levels

   • Too hard to code (3-6h) for only litte:
   • 4 feature is useless and
   • 3 feature is a lot of code refactoring to hold the state of the current blockquote prefix.

This issue is very old. To be clear, 3 and 4 remains some enhancement possibility but I doubt someone will take the time to code them in vim. Otherwise, please open a PR.

[brennen]

I only just noticed this, but the change in dc63a5d breaks blockquote handling for the documented 4-space indent entirely:

Text which starts with 4 or more spaces is a blockquote.

This would be a blockquote in Vimwiki. It is not highlighted in Vim but
could be styled by CSS in HTML. Blockquotes are usually used to quote a
long piece of text from another source.

A <pre><code>...</code></pre> block isn't a blockquote.

It looks like blockquote rendering in general is pretty broken at the moment. As far as I can tell from testing, nothing matches the documentation and multi-line quotes don't seem to work at all.

I'll try to write up a separate issue describing the situation.

[brennen]

I'll try to write up a separate issue describing the situation.

Nevermind - I see this is already captured in #1007.