This is not a part of the splitBlock command in the default commands module, since in a semantic editing markup, where you don’t use strong as a way to give your paragraphs a different semantic meaning, this isn’t something people would do. It is quite easy to write a command that implements the behavior you’re expecting and bind that to enter.
I’d argue appendTransaction is the wrong place for this (since it can only inspect transactions and knows nothing about intent), and a wrapper around the splitBlock command is a better approach.
Considering how basic & common this is I feel it should be the default behavior with an option given to override it. The basic demo for example should definitely have this, to a newcomer it seems broken.
Otherwise can at least a correct solution be posted here ?
@tl[quote=“tjvr, post:6, topic:625”]
I don’t agree. Actually this behaviour would annoy me!
[/quote]
Really? Your expectation is that if you hit bold, type and then hit enter, the application should auto unselect bold for you? Are there specific applications you use that behave like this?
I did a quick survey of existing web editors (tinymce, summernote, ckeditor), Prosemirror class structured editors (quill, slatejs, mobiledoc-kit, trix, draftjs), and Desktop editors (Word, TextEdit, Notes). Mobiledoc-kit and Slate behave in the same way as Prosemirror, the others preserve styles across newlines. I think it’d be surprising behavior to end users in general but I can understand the argument for keeping it as is both from a technical standpoint and just as a differentiator. Just wanted to add some more info to the conversation.
This patch adds a splitBlockKeepMarks command that, after splitting the block, sets storedMarks to the set of marks that were active before the split, so that typing immediately after that will keep your marks.
The example setup already adds the default keymap, which binds enter. If you want to override enter, you should put your keymap before it in the array of plugins, [keymap(...)].concat(exampleSetup({schema}).
When using splitBlockKeepMarks, any idea how to keep empty marks? As soon as I move my cursor PM seems to cleanup empty paragraphs and removes all the spans and only keep the br, here’s a video demonstrating the behavior: https://cloudup.com/ctedmMJzYU9
Couldn’t find where the cleanup happens, I’d be fine with hacking my way around so that these empty marks aren’t removed.
ProseMirror doesn’t keep empty marks—they don’t exist in the document model, and stored marks are considered to be transient, i.e. intentionally reset when the selection changes. You could write a plugin that tracks such marks, but I’m not sure it’s a great idea—it adds a piece of hidden state that isn’t visually obvious to your documents.
I understand your point. I think that it’s fair and desired when the empty mark is surrounded by text, but unexpected when in an empty paragraph, especially with splitBlockKeepMarks. Since PM is probably always used alongside a toolbar, these “hidden” states are usually illustrated with an active state on the buttons/selects.
I think we all have very different use cases for PM and valid reasons on both sides to either want to clear empty marks or keep them, but being able to choose between the two “modes” would be ideal IMO as there doesn’t seem to be a consensus.