alt Hacker News> The second flaw is that a cut reflows the document. A cut and paste is almost always for the purposes of moving text, and yet the instant I cut, the text reflows and I have to locate the point where I want to paste all over again.
It's true that cut and paste reflows text twice (once on cut and once on paste), but it does so in the place where your eyes are already looking. Ghost cut reflows only once (on paste), but it does so in a place where I'm not already looking. I find this much more confusing based on the video.
> Cut & Paste is not atomic
Neither is ghost cut, because if you only cut you're left with grey text as an intermediate state.
> Cut is undoable
...this is the part I agree with, and it seems trivially fixable. If you undo a `cut`, put back whatever was on the clipboard beforehand.
I think it would be confusing if only one app did it, but if an OS decided to implement this system wide, I think it would be a good improvement.
You could also make `copy` possible to undo, but I think that would be weirder since there's no visible effect of your undo action.
Replies
Even if it was 2GB of some data? Even if you run low on memory?
TFA and comments are clearly a solution is search of the problem.
The problem with Undo reverting the clipboard state is that Undo is usually file or app-local, but the clipboard is shared. You can cut from app A, switch to app B, cut something else from app B, then go back to app A and undo the cut.
“Ghost cut” can work across apps with reasonable undo support by not using the clipboard at all and some form of IPC instead. For example, when you cut from app B before resolving the cut from app A, app A could be notified to cancel its cut.
I think this is much less intuitive than the current convention though.