Prosemirror: List item deletion should not join bulleted list with adjacent numbered list

[owjsub]

ref: http://prosemirror.net/demo/basic.html
reproduced on Mac Chrome, iOS Safari, Android Chrome

[WesleyKapow]

Hmmm, I think I disagree. When dealing with lists, I don't ever want:

1. hello
1. world

Instead I want the editor to join these two numbered lists so that I get:

1. hello
2. world

If a user wants separate numbered lists then they should separate them with a newline.

[marijnh]

I think the proposed behavior (though the issue never explicitly states it) is to lift the current paragraph out of the bottom list, and then only move it into the top list when pressing backspace again.

I'm not sure yet that I prefer that. (And I really don't like issues that use 'should' when talking about some debatable property, but that's a different discussion.)

[WesleyKapow]

Ah, I misunderstood. I was assuming the numbered list button was clicked to convert it.

I have many custom list command implementations to tweak the behavior of lists to my liking. And I actually do as @owjsub suggests. Hitting backspace on the bulleted list lifts it, but hitting numbered list on it will convert it and join with the above list.

[owjsub]

For this and other UX/debatable issues, I propose we achieve parity with a classic wysiwyg editor such as MS Word or Google Docs. ref: https://discuss.prosemirror.net/t/auto-changing-active-marks-styles/275

[rafbm]

I think the proposed behavior (though the issue never explicitly states it) is to lift the current paragraph out of the bottom list, and then only move it into the top list when pressing backspace again.

I also assume this is the proposed behavior, and I agree with it. When you are done writing three bullet points and want to delete the “4.” that was automatically inserted…

…the natural reflex is to hit Backspace, not Enter. The current behavior of turning the fourth bullet into a second paragraph of the third bullet seems unexpected:

Apple Pages and Google Docs both clear the “4.” and put you into an empty paragraph after the list.

I tried to hack my way around this and while it’s fairly easy to add lift before joinBackward in the Backspace chainCommands, is it not viable because of the way joinBackward behaves once you are in an empty paragraph after the list. Backspace joins back into a _new empty item_ at the end of the list, so you end up in an endless Backspace loop:

I think this leads us to the second half of the same issue. It would be more intuitive for joinBackward to join back at the end of the list’s last item, rather than create a new one. I don’t think anyone expects Backspace to create something new somewhere, it should just delete stuff backwards.

To sum up, the way Apple Pages and Google Docs handle the Enter => Backspace => Backspace flow sounds like the best option:

Note: if this behavior change is accepted, it would make sense for it to also apply to blockquotes:

Backspace would move the cursor at the end of the “Quoted paragraph 2.” line rather than create a third paragraph in the blockquote. I would guess the same code change will affect both lists and blockquotes at once, but Marijn sure knows best here.

[marijnh]

Removing the joining behavior from backspace's command would remove the most obvious way to join list items, and require a custom command for that. While I see what you mean, it's just not that easy. (Google docs don't nest nodes, and thus have a much simpler model to work with. But I do think their continued-list interface, which seems to be pressing shift-enter in a list item, isn't great.)

One option would be to change backspace to always lift out of the surrounding block or, when further lifting isn't possible, directly join with the previous textblock. But that'd break the symmetry with delete-at-end-of-textblock, and make it much harder to create continued list items.

[owjsub]

@marijnh Is it safe to remove the joining behavior only when selection is at the beginning of the first list item or last list item in a non-nested list?

[marijnh]

That doesn't really help, since the typical point where you'd want to join list items is right after creating a new one, typically at the end of the list.

[owjsub]

I was referring to backspace when selection is on the first or last list item in a non-nested list. Is that a typical point where you'd want to join list items?

[marijnh]

Yes...

[owjsub]

Sorry, maybe i'm misunderstanding how a join works...

[marijnh]

Say you have

1. foo
2. bar|

And you press enter

1. foo
2. bar
3. |

But you actually wanted to continue that list item, so you press backspace

1. foo
2. bar
   |

The joining of list items corresponds nicely to the visual 'rubbing out' of the list marker to the left of the cursor, so I think backspace is a rather obvious control for this.

(At some point, pressing enter in a ProseMirror list item kept you in that item, and you had to press enter again to get out of it, but people got upset about this.)

[bZichett]

The joining of list items corresponds nicely to the visual 'rubbing out' of the list marker to the left of the cursor, so I think backspace is a rather obvious control for this.
(At some point, pressing enter in a ProseMirror list item keps you in that item, and you had to press enter again to get out of it, but people got upset about this.)

That sounds not so different from the inverse of what @rafbm is getting at.

I would much prefer a single backspace clearing the list _and_ the 'continued list' (defined as the same indentation, newline, with no new number / bullet point. Google Docs being a good example, albeit aware of the flat underlying data structure. No, not upset about it. But quite certain this makes for a better UX.

In a way, continued list are an anti-pattern. If a list is continued but requires the end of a sentence in which the next sentence doesn't immediately follow it, it seems like a new list item to me

I'm an extreme proponent of hierarchical lists and never use continued lists.

Wouldn't mind just having shift+enter for continued lists.

Also curious what's all your use cases for them?

[billyshena]

Agreed, would be great to have this behaviour 👍
Any updates on this ?

[bZichett]

@billyshena It seems it a user opinionated issue (down to preference and what "feels" right). @marijnh if there is applicable history of that past prosemirror functionality, perhaps we could link it here first and then maybe we can try making it part of the passed-in configuration?

Someone else could also try to figure out a way to do this if they'd like (I can try on some free time, myself but would like at least the git commit where this happened)

[marijnh]

I'm going to close this—I think the default behavior is reasonable, and it's possible to override it with a custom command when you want something different.