linebreakReplacement node isn't used during joinForward/joinBackward operations

[gpolzinatlassian]

Previously I had reported an issue (#1460) with newlines collapsing when converting code blocks to paragraphs (or other block types) when using either setBlockType or as a result of a joinForward/joinBackward operation.

The outcome of this was the introduction of the linebreakReplacement property that can be optionally applied to our hardBreak node so that it would replace newlines during these conversions instead of them being replaced by spaces.

Admittedly we've been very slow to adopt this, but I'm implementing this now in our editor and I can see that the lineBreakReplacement node is not used during joinForward or joinBackward operations that are invoked by the backpace/delete key.

Looking at the source (ProseMirror/prosemirror-transform@a0ab849) I can see that the property is only used by the setBlockType transform, whereas joinForward/joinBackward continue to invoke the clearIncompatible transform which removes newline characters, ignoring lineBreakReplacement.

Is it possible joinForward/joinBackward' can behave similarly to setBlockType on these occasions and respect the linebreakReplacement setting?

Steps to reproduce:

1. configure an editor with the basic schema and linebreakReplacement : true enabled for the hard_break node.
2. Add a paragraph of text, with a code node below it with multiple lines of code.
3. Move cursor to the first position of the code node and press backspace (invoking joinBackward

Actual result:
Code is joined into the preceding paragraph with it's newlines being replaced by spaces.

Expected result:
Code is joined into the preceding paragraph with it's newlines being replaced by hard_break

[marijnh]

That's a good point. Attached patch implements this.

[gpolzinatlassian]

That's a good point. Attached patch implements this.

Awesome, thank you!

[gpolzinatlassian]

Hi @marijnh, sorry to be a pain but in doing some testing I think I've found an issue with this fix. The lineBreak replacement is done in the join() transform, however for joinForward/joinBackward for non-isolated nodes like this, join is invoked via joinMaybeClear here in deleteBarrier.

joinMaybeClear chains this with a clearIncompatible in front of the join (here) and clearIncompatible does it's own removal of linebreaks - replacing them with spaces, so they will be gone already before join tries to replace them.

Unrelated: there's a small spelling typo in the function name "canAppendWithSubstitutedLinebeaks"

[marijnh]

That's a good point. Kind of awkward to arrange for these removals and replacements to be done in the correct order, so I've moved the responsibility for cleaning up inline nodes/marks into join as well, and made joinMaybeClear depend on that.

[gpolzinatlassian]

Thanks! I've ran some tests and that appears to be working as expected now. 🎉