Backspacing ranges with dissimilar node types

1

In my editor, when a user selects a range that goes from one type of node to a different type of node, I want to delete the selected end of the first node, the selected text that starts in the last node, and all contained nodes in the selection range, but I do NOT want to combine the first and last paragraphs (as they are not the same type of paragraph).

As an example, consider a paragraph and a quote…selecting from the middle of the paragraph into the middle of the quote should leave the paragraph shortened and also lave the quote shortened, but should not take the leftover quote text and just slop it into the paragraph.

I have not investigated the joinBackward and deleteSelection built-in commands, although I do have my own custom backspace command that I want to augment with this edge-case addition. I already do not allow one type of paragraph to get backspaced to join a different type, but this is a related but separate case where the range spans nodes.

Any help or guidance on this would be very welcome.

Ben Cahan

2

I got this to work in my custom backspace command by separating the delete into three sections: the stuff at the end if the first node, everything in between and then the selected text at the start of the final node:

            tr.delete(EndnodeStart, rangeEnd);
            tr.delete(StartnodeEnd+1, EndnodeStart-1);
            tr.delete(rangeStart, StartnodeEnd);
            tr.setSelection(TextSelection.create(tr.doc, rangeStart));

The variables should be fairly obvious to understand here.

So, the resulting question is whether this action should really be put into a plugin that handles all keys, not just the backspace key (which is where this code sits now). And, of course the same code should be put wherever there is a selection being replaced, such as with pastes and cuts as well.

I’d love advice on the best strategy with this to keep dissimilar node types separate and not joined together, which would make no sense in my implementation.

3

This behavior is kind of a fundamental assumption in this style of editing—that it’s possible to join blocks and move their content into another block. The library doesn’t support what you’re looking to do here directly, so indeed, I’m afraid you’re going to have to address each editing pattern separately (and it may not be possible to catch them all).