Before implementing it myself I am wondering this would be an enhancement to the selectNodeForward and selectNodeBackward commands.
For the case when the selection is at the end of a paragraph with text, the selectNodeForward command move the selection to the next node and makes it a NodeSelection. This behaviour can be seen here Recordit: Record screencasts fast & free! with GIF Support!.
For the case when the selection is at the end of a paragraph without text, the joinForward command move the selection to the next node and makes it a NodeSelection or a TextSelection. This behaviour can be seen here Recordit: Record screencasts fast & free! with GIF Support!.
In the joinForward command there is a check to see if the node is textBlock and if it is then a TextSelection is set instead of a NodeSelection
I’m not entirely sure what you mean. But joinForward does this after is has deleted something, i.e. after it already had an effect. selectNodeForward does not delete anything. The idea is to select a node, so that another Delete press can delete it.
My product owner find that it is weird that the cursor goes to different places depending on if there is text in the paragraph before or not. My idea was to change selectNodeForward to put the cursor inside the node if it is a textblock. I understand the idea behind the node selection but they don’t like it. I can reimplement it myself if this is too specific for the library itself.
If I understand you correctly, you’re talking about pressing delete at the end of a textblock that is in front of a node that can’t be joined but also isn’t a leaf node. If the textblock with the cursor is empty, it is deleted and the cursor is moved to the first textblock in the node after. If it isn’t, the node is block-selected.
If that is accurate then yes, I think adding custom logic to implement what you want to happen is the way to go here.
