Undo manager should wrap reinserted text

[quangbuule]

Selection UX is really bad. For example when we select text to delete, then we undo after deleting, the selection should wrap that text (also be forwards or backwards if needed). I think we should store selection to stacks also.

[jhchen]

I think an acceptable heuristic is just wrap reinserted text that was deleted? Also what do you mean by forwards or backwards?

[quangbuule]

Backwards mean the selection start from the right, and end to the left (by Shift + Left). The difference compare to forwards is after we do a backwards selection, we press Shift + Left again then the selection should expand to the left. Currently quill.setSelection cannot do that, I have to write quill.prototype.setBackwardSelection for my case.

[quangbuule]

Wrap reinserted text is ok, but the undo manager is not doing right in other case also so I think the implementation of _getLastChangeIndex is not correct in UX perspective. For example, we deleted this text "Lorem ipsum" then undo, the selection move to right before the "ipsum" while we expected it should be right after ipsum.

Can you explain the implementation of _getLastChangeIndex? I was confused when I read it.

[thomsbg]

I just noticed this behavior too.

I think an acceptable heuristic is just wrap reinserted text that was deleted? Also what do you mean by forwards or backwards?

I think I'd amend this to make it more precise by saying: if the last op of the original delta was a highlight-and-delete, then the restored characters should be selected when that delta is un-done.

The problem is, it's impossible to know whether a { delete: 1 } op came from a highlight-and-delete operation, or from a simple backspace. Perhaps this means that the clipboard module needs to keep track of selection history?

[thomsbg]

@jhchen I encountered another reason for the clipboard module to track the selection history. I have a key binding set up to turn 1/2 into ½ once the spacebar is pressed, resulting in ½ (including the inserted space).

I have more similar keybindings to accomplish the same for -- => — (emdash), " => “ (curly quotes), etc.

My key bindings insert the space first, before calling history.cutoff() and doing the automatic transformation. I would like the editing UX to be such when you press undo, the automatic transformation is undone, keeping the inserted space, and keeping the selection unchanged (after the inserted space) to be able to continue typing seamlessly.

Right now, the act of undoing the change from 1/2 into ½ moves the cursor before the inserted space, because of the getLastChangeIndex logic in the clipboard module. Ideally, the history module would capture the selection when it calls record(), and then would restore that range after applying the undo/redo delta. That way, the selection can be restored accurately to what it was at the time the original change was made (i.e. after the space in this case).