Comment by Wowfunhappy | Hacker News Reader

Comment by Wowfunhappy | Hacker News Reader

Parent Full thread

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

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.

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

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.

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

I agree! There’s nothing to fix.

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

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.

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?

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.

Yes?

Just open a .BMP or .TXT of your desired size, copy it contents to the clipboard, close the app and paste to anywhere else.

Sure, sometimes it's a ref, eg: files, but sometimes it's just plain data.

Reply on news.ycombinator.com