[SUGGESTION] Design choices for blockquote formatting helpers

I often times work with the blockquote block in my writings, as much of my work revolves around correspondence, and I also do a fair amount of transcription, either from audio or printed material. Subsequently, I end up typing within quotation environments more often than the average person might (who knows though).

nvUltra has some interesting options that promise to make this process easier:

1. As a return key behaviour: **Automatically insert '>' in blockquotes**
2. As a post hoc formatting command on a selection: **Format ▸ Convert Selection To ▸ Convert to Blockquote**.

In practice however, these two functions seem to rarely produce a desirable result, and in one case, the produced result seems to me as though it would never be of much use to anyone (but I'm surely missing something as it all looks intentional!).

# Menu Command Conversion

## Block continuation vs sequential formatting

First let's look at the menu command. If you were to type in three properly formatted Markdown paragraphs, select them all, and then apply the command, you would get:

```
> Paragraph one...

> Paragraph two...

> Paragraph three...
```

The problem with this, is that as I understand it, and in observation of how CommonMark (and thus MultiMarkdown) parses and converts this output---is that this is not well-formed for what we are intending to do here---have a three paragraph quotation in the text. What we in fact have here are three individual block quotes, semantically speaking, each with one paragraph within them. Here is what we get in LaTeX:

```
\begin{quote}
Paragraph one{\ldots}
\end{quote}

\begin{quote}
Paragraph two{\ldots}
\end{quote}

\begin{quote}
Paragraph three{\ldots}
\end{quote}
```

This problem manifests as a formatting issues since the semantics are wrong. The paragraphs are spaced out far too much in most LaTeX setups, and I believe the same might be true for HTML as well.

While I could see an argument for one using this menu command to format multiple *separate* quotations sequence, and thus find this output desirable, to my mind this is a far more unusual occurrence than formatting a multi-paragraph quotation. Particularly in print, block quotes are most often used in cases where a quotation spans multiple paragraphs. So to my mind, the most desirable and expected output should be:

```
> Paragraph one...
> 
> Paragraph two...
> 
> Paragraph three...
```

This produces the desired semantic result (as described in [CommonMark E.g. 214]):

```
\begin{quote}
Paragraph one{\ldots}

Paragraph two{\ldots}

Paragraph three{\ldots}
\end{quote}
```

One final point in this section, and perhaps even a consequence of this design change (if each line is treated separately by the command): it would make sense to embellish the current line with `> ` even if that line is currently empty. The current behaviour seems odd to me as a command result. Why do nothing at all, what violations of proper usage exist here that we would want to avoid by having the command refuse the user's request?

Meanwhile, if it did work, then it would be the most efficient way to start a new blockquote line as it is one keystroke event vs two. Sure, one can achieve that result by typing or pasting first, and then using the keystroke---but again, why deny the request when it simply makes sense to execute the user's intention? Why enforce one way of input when either way is perfectly valid.

[CommonMark E.g. 214]: https://spec.commonmark.org/0.29/#example-214

## Nesting blocks quirk

The other issue we have with this command is that it only works once, and after that point it works oddly (I'm pretty sure this is a bug). As is more typical in correspondence, you sometimes need to quote yourself a bit as well as the person you are responding to, resulting in something like this:

```
> > What I said...
> 
> What they said...
```

If I press `⌘'` on the first line twice, the first time adds `> ` as expected, but the second use only adds a single space in front of the angle bracket, rather than angle + space, causing the effect of visually indenting the line (eventually you'll turn it into a code block). So that definitely seems like a bug to me.

# The Return Key Behaviour

Lastly, the **Automatically insert '>' in blockquotes** setting produces a result I don't really understand the usefulness for. I suppose if one is inclined toward hard-wrapping their lines by hand, then this would be useful...

```
> Line one ... to 30 columns
> and on we continue ... to
> the next.
```

This would produce a single paragraph in a quoted environment, but not many people *write* that way! Most people are content to let the editor soft-wrap for them, and if they need to hard-wrap, use an editor tool to handle that grizzly job automatically (or even in a completely out-of-sight fashion as email clients do). Pasted quotations may often be hard-wrapped, but in that case this specific return key helper isn't relevant.

In case I'm not making much sense here, the real problem with how this feature is set up is that if you press ↩ on a line that contains nothing but `> `, then it interprets the request as "I'm done typing in this blockquote", when the only commonly useful thing you might want this feature for in the first place is to be able to write multiple paragraphs in a quotation without having to prefix each line with `> ` yourself. So I'd want:

```
> One
>
> Two
```

...as a result from this setting, but it never produces that because the middle line separating the two quoted paragraphs has the syntax removed. There are two approaches I can think of to solving this conundrum:

1. Return clean-up simply never happens for blockquotes. You will get a thousand lines prefixed with `> ` even if they are all blank. It is up to the user to hit ⌘delete, or delete + delete, as they prefer, to exit a blockquote. This approach would also be enhanced by my suggestion to have a [return override] behaviour, where one would press ⌘↩ (or whatever) at the end of "One" to head straight out of the environment if that is what they want.
2. Handle a second empty line as a request to terminate the blockquote environment. So in fact we would be cleaning *two* lines. In this case, if instead of typing "Two" in my previous example, I hit Return, then the `> ` prefixes on both the current line and the previous would be removed, and the cursor would be left on the current line. If I were to type in "Two" at that point, I would get:

```
> One

Two
```

Are there cases where that would be undesirable, where one might actually want multiple sequential empty cosmetic lines in a block quote environment? Perhaps... but I can't imagine the number of people wanting that would outnumber those who would want the Return key behaviour to be useful beyond hard-wrap writing styles.

The first option is safest, it makes no assumptions about what the user wants, but it's also a bit perhaps overly cautious. I think the second option is pretty safe, and hey if someone really wants two or three empty lines purely for the sake of editor cosmetics, they could achieve that by

[return override]: https://multimarkdown.zendesk.com/hc/en-us/community/posts/360031640234