That’s interesting – I hadn’t noticed this pattern before.
If we ⌘-click to create a discontinuous selection like:
and then ⌘X to cut
The cut does apply to all selections, but the pasteboard retains only the first selection for pasting.
Here, for example, both alpha and epsilon are deleted from the edit buffer, but only alpha is transferred to the pasteboard.
Perhaps that’s by design ?
OK, yes I see, so given a discontinuous selection like,
in the os x control,
for the model we see:
editor.selection.selectedItems.length === 1
and after a single ⌘X deletes all three lines, we need three taps of ⌘Z to restore all three.
Perhaps I had forgotten that.
Yeah, I think TaskPaper only maps the first selection to it’s internal model. And that’s what is used for the Copy to clipboard. On the other hand it lets NSTextView do the actual editing… that’s what the multiple selections are effected. I should probably disable multiple selection in the NSTextView… thought I already had.
Got it, and it sounds as if the undo stack which the NSTextView is using would not be very practically accessible to script.