Handle block quote like list item in editor

[Jmuccigr]

In the editor, if you are editing a list item and you git return, you get a new line that starts with a list item marker. Hit return again without typing further on the live and you get another new line and the item markers disappear.

I like this.

In contrast, if you're in a block quote, new lines will all have the indicator at their starts (>), no matter that the line had nothing in it.

I don't like this and suggest modifying the behavior of the editor in block quotes to match that in lists.

[FranklinYu]

Yeah that would be pretty sweet, but what if one wants something like

> First paragraph.
>
> Second paragraph.

? I'm thinking like "hitting Return ↩ one more time": hitting it first time gives another >, and hitting it second time removes the two > created before.

[Jmuccigr]

If you want to do that, just put a space after the second >. Both a space and nothing give you a blank line in the middle of the quotation.

For my part, quotation with blank lines is pretty rare, much rarer than wanting to end a quotation after one block.

[ukiahsmith]

I like the idea of a second return on a bank > removing it and adding another return. I find myself accidentally adding blank > lines after I paste in text to a blockquote.

I would also recommend having a shift + return on a single > to keep it in place and add an additional > on the next line. This would be in addition to have a > plus a space indicated a blank blockquote line.

[uranusjr]

So I would guess, from the context, what you want is just auto insert the >, not a space after it? Currently list markers are inserted with a trailing space.

Why I implemented it this ways is exactly what @franklinyu described—to difficult to handle the new paragraph behaviour. This will need to be settled on if we are to implement this auto completion.

[ukiahsmith]

Let me clarify.

I think two changes could be made.

1. If a line is only a > (greater than and space) and return is pressed, remove the > and move to the next line. Now there is a blank line between the block quote and the cursor position.
2. If a line is only a > (greater than and space) and shift+return is pressed, keep the >, move to the next line, and enter a new >.

The space would continue to be auto inserted with the greater than character.

[uranusjr]

@UkiahSmith MacDown doesn’t currently give shift-return any special meaning, so it might be a bit strange to that here. But I do like the idea on a whole. Are there any other situations we can implement a similar behaviour and make shift-return a more general thing?

[ukiahsmith]

For lists we could a shift-return to indent the next new bullet. We could also have another {cmd}+space to outdent the next bullet.

The way bullet'd lists work is how I would like the blockquote to work. If the line is empty, except for the formatting of * (star space), and return is pressed the star space is removed and the cursor moved to the next line. Implementing item 1 from my previous comment would bring blockquotes more in line with how lists work.

[uranusjr]

⌘+space is already mapped to new paragraph (i.e. two newlines, all autocompletion disabled), so that’s no go. Maybe shift-opt-return (opt = something similar but different than the original behaviour).

[uranusjr]

Anyone reading this please give this a try if you want to. :)

[Jmuccigr]

⌘+space is already mapped to new paragraph (i.e. two newlines, all autocompletion disabled), so that’s no go. Maybe shift-opt-return (opt = something similar but different than the original behaviour).

Who knew? ;-)

Seriously though, command space for a new paragraph seems superfluous if the list item behavior is generalized. Just hit return twice in any context to return to regular text in a new paragraph.

[devtanc]

Most people have ⌘ + space mapped to spotlight on the Mac. And I'd say that it's really rare for me, personally, to use any shortcut that take more than two buttons. At times I do, but they're just harder to remember and get in practice of using. I really like the idea of the shift + return ↩.

[FranklinYu]

FWIW, I map ⌘ Command Spacebar to “change input method” action.

[ukiahsmith]

Ha. I should I have remembered that ⌘ + Spacebar maps to Spotlight. I use it all the time.

So right now lists (bullet and numbered) act different than blockquotes. I think having them work the same would be more consistent.

1. If a line is only a > (greater than and space), or * (star space), or 1. (number dot space) and return is pressed, remove the item and move to the next line. Now there is a blank line between the block quote and the cursor position.
2. If a line is only a > (greater than and space), or * (star space) or 1. (number dot space) and shift+return is pressed, keep the item, move to the next line, and enter a new item of the same type.

I do not see use usefulness of using shift+return with lists, but it seems like consistency would be better. This would also have blockquotes act more like I would desire.