Fenced block quotes

[mtsknn]

Long block quotes are annoying to type and maintain because each line needs to start with >:

Paragraph before quote.

> Multi-line
> paragraph.
>
> Another paragraph.
>
> ```js
> const foo = 'bar'
> ```
>
> - ham
> - spam

Paragraph after quote.

Sometimes the > prefix can be omitted (in this case probably only from the second line), but I think that looks worse. (But it's useful; when writing Markdown, I often omit unnecessary >'s and let Prettier add them automatically when I save the file.)

It'd be nice to have fenced block quotes, e.g.:

Paragraph before quote.

>>>
Multi-line
paragraph.

Another paragraph.

```js
const foo = 'bar'

• ham
• spam

Paragraph after quote.

Pros:

- Long block quotes are easier to type and maintain
- Syntax is readable and clear (I often use this syntax for long block quotes when writing plaintext)
- Delimiter is familiar and logical (`>>>` vs `>`, also `` ``` `` vs `` ` ``)

Cons:

- More syntax

More or less related issues:

- #29
- #41

[jgm]

I'm against this, I think. Fenced environments are not great, because of their non-locality (you can't tell from the local section of text whether it's part of the environment). Indeed, I'd probably prefer a side-marked syntax to the current fenced Divs, for that reason, but I'm willing to accept the idea that fenced divs are a necessity because the contents are often quite long. Block quotes are usually not that long, and it's better that they're visually set off as distinctive.

[hellux]

Text editors can usually handle the current blockquotes quite seamlessly in my experience, just like with similar comment styles in programming languages.

In my opinion, the existing syntax is clearer, it is always directly visible what is within a quote. For the suggested syntax, one has to keep track of the openers and closers. Though, the > may make it look noisy, at least if the blockquote content is complicated.

This would add another global block level delimiter like the div fence (:::). It already adds some complexity to the block parsing (see e.g. #109). Having both a div container and a blockquote container would introduce overlap of block containers (similar as for inline containers):

E.g.

:::

a

>>>

b

:::

c

>>>

must be handled somehow, as they cannot overlap in the AST/HTML. I guess the blockquote would become a child of the div and automatically close when the div closes, causing the closer to become an opener instead:

<div>
<p>a</p>
<blockquote>
<p>b</p>
</blockquote>
</div>
<p>c</p>
<blockquote>
</blockquote>

[jgm]

To me, your first example is much more readable in the plain text than the second. With the second, your eye has to find the open and close fences and then think of the enclosed contents as distinctive, much more work! We aim to satisfy the markdown prime directive of source readability.

[mtsknn]

Hmm, I actually agree that the first example is much more readable. Also good point that it's easier to parse.

I'll close this issue. 👍

Text editors can usually handle the current blockquotes quite seamlessly in my experience, just like with similar comment styles in programming languages.

Guess I need to learn new text editor tricks to make typing and editing long block quotes more comfortable.

In VS Code Cmd+/ toggles the HTML comment syntax by default. Maybe I could change that to toggle the quote syntax, or assign a new keyboard shortcut for that.

For anyone interested, here's how I have previously prepended > to several lines in VS Code with the amVim extension; these are ok but not great:

• First method
  1. Add cursors to lines below/above with Opt+Cmd+↓/↑
  2. Prepend > to the lines with I+>+Esc
• Second method
  1. Select a range in visual line mode (e.g. V+3+j)
  2. Add cursors to end of lines with Opt+I
  3. Prepend > to the lines with I+>+Esc
• Third method (this should work in plain Vim as well)
  1. Prepend > to the first line with I+>+Esc
  2. Prepend > to lines below by spamming j+.

[hellux]

• Third method (this should work in plain Vim as well)
  1. Prepend > to the first line with I+>+Esc
  2. Prepend > to lines below by spamming j+.

Plain vim also allows vip^VI> ^[ (visual select paragraph, block visual mode, insert >)

Also, it will automatically wrap the line when you exceed the max width while typing, adding > to the new line. Automatic wrapping can also be achieved afterwards with gq, with > on each line.

[dumblob]

Aside from this proposal, let me note that the major advantage of markups (djot including) for me is that they are pleasant to write (and also read but that has slightly lower priority than writing).

And requiring > at each line defeats this purpose. Why? Because line splitting (required by the > syntax) is manual work (otherwise we do not talk about plain text but suddenly about wysiwyg-like editing UX for which no markup is necessary and I can use any of those gazillions of rich text editors) while juggling with text.

Thus for years I am forced to write one and only one > at the very beginning of each long paragraph just to keep me sane during editing. But that makes it look as ugly as

>>>
...
>>>

with the downside I am still a tiny bit more limited when juggling with the paragraphs.

From time to time the hell wreaks havoc when I need nested block quotes. Then all these ugly things become even uglier and editing experience is virtually 0 as seeing the following mixture is IMHO worse than >>> >>> pair.

> santoehu snatohu sntahousnt ahou snthaosu nthaosun thaosnu
tasonu thason tuhsaon tuhsano tuhsnaoth usnatoh usnaoth usnaothu  
sanoth usnaot husnaot husnathoue sntahosu nthaosnu thaosnu 
thasnout hsanoth usnaot husnato heeusnat hou sntahous nhaosu 
nthaos untaos unoe snt hao usnth ao sunthaosu nthao usnhtaosu 
nthaosun htasu nthaousn thaoseun thaosu thaosu nthaoesu nthaosu 
nthaosu thaosu h ao suntha o ussta hou ssao husntaho usntahou 
snathoue snaoth usnta housntha ousntahou snth aou snt haousnato 
husao th
>>> santoehu snatohu sntahousnt ahou snthaosu nthaosun thaosnu 
tasonu thason tuhsaon tuhsano tuhsnaoth usnatoh usnaoth usnaothu  
sanoth usnaot husnaot husnathoue sntahosu nthaosnu thaosnu 
thasnout hsanoth usnaot husnato heeusnat hou sntahous nhaosu 
nthaos untaos unoe snt hao usnth ao sunthaosu nthao usnhtaosu 
nthaosun htasu nthaousn thaoseun thaosu thaosu nthaoesu nthaosu 
nthaosu thaosu h ao suntha o ussta hou ssao husntaho usntahou 
snathoue snaoth usnta housntha ousntahou snth aou snt haousnato 
husao th
>> santoehu snatohu sntahousnt ahou snthaosu nthaosun thaosnu 
tasonu thason tuhsaon tuhsano tuhsnaoth usnatoh usnaoth usnaothu  
sanoth usnaot husnaot husnathoue sntahosu nthaosnu thaosnu 
thasnout hsanoth usnaot husnato heeusnat hou sntahous nhaosu 
nthaos untaos unoe snt hao usnth ao sunthaosu nthao usnhtaosu 
nthaosun htasu nthaousn thaoseun thaosu thaosu nthaoesu nthaosu 
nthaosu thaosu h ao suntha o ussta hou ssao husntaho usntahou 
snathoue snaoth usnta housntha ousntahou snth aou snt haousnato 
husao th
> > > santoehu snatohu sntahousnt ahou snthaosu nthaosun thaosnu 
tasonu thason tuhsaon tuhsano tuhsnaoth usnatoh usnaoth usnaothu  
sanoth usnaot husnaot husnathoue sntahosu nthaosnu thaosnu 
thasnout hsanoth usnaot husnato heeusnat hou sntahous nhaosu 
nthaos untaos unoe snt hao usnth ao sunthaosu nthao usnhtaosu 
nthaosun htasu nthaousn thaoseun thaosu thaosu nthaoesu nthaosu 
nthaosu thaosu h ao suntha o ussta hou ssao husntaho usntahou 
snathoue snaoth usnta housntha ousntahou snth aou snt haousnato 
husao th
> santoehu snatohu sntahousnt ahou snthaosu nthaosun thaosnu
tasonu thason tuhsaon tuhsano tuhsnaoth usnatoh usnaoth usnaothu  
sanoth usnaot husnaot husnathoue sntahosu nthaosnu thaosnu 
thasnout hsanoth usnaot husnato heeusnat hou sntahous nhaosu 
nthaos untaos unoe snt hao usnth ao sunthaosu nthao usnhtaosu 
nthaosun htasu nthaousn thaoseun thaosu thaosu nthaoesu nthaosu 
nthaosu thaosu h ao suntha o ussta hou ssao husntaho usntahou 
snathoue snaoth usnta housntha ousntahou snth aou snt haousnato 
husao th
>>> santoehu snatohu sntahousnt ahou snthaosu nthaosun thaosnu 
tasonu thason tuhsaon tuhsano tuhsnaoth usnatoh usnaoth usnaothu  
sanoth usnaot husnaot husnathoue sntahosu nthaosnu thaosnu 
thasnout hsanoth usnaot husnato heeusnat hou sntahous nhaosu 
nthaos untaos unoe snt hao usnth ao sunthaosu nthao usnhtaosu 
nthaosun htasu nthaousn thaoseun thaosu thaosu nthaoesu nthaosu 
nthaosu thaosu h ao suntha o ussta hou ssao husntaho usntahou 
snathoue snaoth usnta housntha ousntahou snth aou snt haousnato 
husao th
>> santoehu snatohu sntahousnt ahou snthaosu nthaosun thaosnu 
tasonu thason tuhsaon tuhsano tuhsnaoth usnatoh usnaoth usnaothu  
sanoth usnaot husnaot husnathoue sntahosu nthaosnu thaosnu 
thasnout hsanoth usnaot husnato heeusnat hou sntahous nhaosu 
nthaos untaos unoe snt hao usnth ao sunthaosu nthao usnhtaosu 
nthaosun htasu nthaousn thaoseun thaosu thaosu nthaoesu nthaosu 
nthaosu thaosu h ao suntha o ussta hou ssao husntaho usntahou 
snathoue snaoth usnta housntha ousntahou snth aou snt haousnato 
husao th
> santoehu snatohu sntahousnt ahou snthaosu nthaosun thaosnu 
tasonu thason tuhsaon tuhsano tuhsnaoth usnatoh usnaoth usnaothu  
sanoth usnaot husnaot husnathoue sntahosu nthaosnu thaosnu 
thasnout hsanoth usnaot husnato heeusnat hou sntahous nhaosu 
nthaos untaos unoe snt hao usnth ao sunthaosu nthao usnhtaosu 
nthaosun htasu nthaousn thaoseun thaosu thaosu nthaoesu nthaosu 
nthaosu thaosu h ao suntha o ussta hou ssao husntaho usntahou 
snathoue snaoth usnta housntha ousntahou snth aou snt haousnato 
husao th
>> santoehu snatohu sntahousnt ahou snthaosu nthaosun thaosnu 
tasonu thason tuhsaon tuhsano tuhsnaoth usnatoh usnaoth usnaothu  
sanoth usnaot husnaot husnathoue sntahosu nthaosnu thaosnu 
thasnout hsanoth usnaot husnato heeusnat hou sntahous nhaosu 
nthaos untaos unoe snt hao usnth ao sunthaosu nthao usnhtaosu 
nthaosun htasu nthaousn thaoseun thaosu thaosu nthaoesu nthaosu 
nthaosu thaosu h ao suntha o ussta hou ssao husntaho usntahou 
snathoue snaoth usnta housntha ousntahou snth aou snt haousnato 
husao th

[jgm]

I do give some priority to "easy to read." I think that was a good goal of original Markdown.

Note that because of "laziness" you can get away with one > at the beginning of each paragraph, even with hard wrapping.

[dumblob]

I do give some priority to "easy to read." I think that was a good goal of original Markdown.

I see.

Note that because of "laziness" you can get away with one > at the beginning of each paragraph, even with hard wrapping.

Yes, and that is a reason why I am not arguing against the current djot spec about >.

I only wrote it to counter the arguments raised above about the "read" advantages as I mostly do not read the source any more after editing but only its rendered variant. Therefore my focus on editing experience (which includes also reading).

If fenced block quotes will not be added, I will still consider djot a better commonmark/markdown but I will probably hesitate to call it a next-gen markup :wink:.

[jgm]

You can just use a fenced div like and then a simple filter to transform this to a block quote.

% cat bq.lua 
return {
  div = function(el)
    if el.attr.class == "quote" then
      el.attr.class = nil
      el.tag = "blockquote"
    end
  end
}
% djot -f bq.lua
::: quote
hi
:::
<blockquote>
<p>hi</p>
</blockquote>

[jgm]

This is a nice example of how djot is meant to be customized.

[mtsknn]

You can just use a fenced div like and then a simple filter to transform this to a block quote.

Looks very good! I think this further obviates the need for dedicated syntax for fenced block quotes.

[dumblob]

Ok, that is a good idea - that might solve my concerns :wink:. Thanks!