> 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.

▲

drdexebtjl 11 hours ago | parent | next [-]

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.

▲

Wowfunhappy 11 hours ago | parent | next [-]

> 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.

...right, thanks. So you could still make it work but you'd definitely need OS support, it's not something one app can fix.

Edit: You could make this work on an app level by checking if the contents of the user's clipboard is still the value they cut. If yes, revert to whatever clipboard contents you saved prior to the cut. Otherwise do nothing.

It's probably too much hidden behavior to be a good idea, but I think it would match what the user wants in 99% of cases.

▲

drdexebtjl 10 hours ago | parent [-]

What would be in the clipboard after the undo in that scenario?

edit: Yeah, the problem is that the user does not expect undo to do something different depending on what they did on a different program.

Undo doing nothing to the clipboard always is more consistent and the better UX.

▲

Wowfunhappy 10 hours ago | parent [-]

...yeah. But I still think these problems apply to Ghost Cut too. Unless the idea is that Ghost Cut only works within one app and/or the content lives in a special ghostboard separate from the clipboard, which I think is equally bad UX.

	▲	drdexebtjl 7 hours ago \| parent [-]
		I agree! There’s nothing to fix.

▲

0gs 11 hours ago | parent | prev | next [-]

wow OS-level undo would be a way cooler solution to this problem

▲

11 hours ago | parent | prev [-]

[deleted]

▲

justsomehnguy 10 hours ago | parent | prev [-]

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.

▲

Wowfunhappy 10 hours ago | parent [-]

Is it possible to copy 2GB of data to the clipboard? If it's an image or something I'd expect the clipboard to contain a reference to the image or some such. How do clipboard managers handle this?

	▲	drdexebtjl 6 hours ago \| parent [-]
		Yes. It contains a reference to the image in the source application. When you paste, X or Wayland lets the source application communicate with the destination application to send the image over. You’ll likely always have a very simple clipboard manager that stores a single copy of the clipboard so you don’t rely on the source application staying alive. Clipboard managers are free to store the clipboard anywhere.