Ghost Cut – or why Cut and Paste is broken everywhere

Posted by willm 9 hours ago

Ghost Cut – or why Cut and Paste is broken everywhere(ishmael.textualize.io)

111 points | 80 commentspage 4

theowaway 3 hours ago|

why is this not an article abour the abomination of paste with formatting

alehlopeh 6 hours ago||

Every implementation is the same, and no spec exists, so how is it broken?

akkartik 6 hours ago||

Hmm, now I'm wondering if paste should save the clipboard contents before so undo can restore them.

But no. Your text editor is a cottage surrounded by an outdoors it doesn't control. It makes no more sense to try to take charge of the clipboard than of a flock of geese flying overhead. What if someone or some other app pasted something in between? Paste is an arrow shot, a message in a bottle.

Wowfunhappy 7 hours ago||

> 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 6 hours ago||

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 6 hours ago|||

> 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 5 hours ago||

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 5 hours ago||

...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 2 hours ago||

I agree! There’s nothing to fix.

0gs 6 hours ago||||

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

justsomehnguy 5 hours ago||

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 5 hours ago||

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 1 hour ago||

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.

tibbydudeza 3 hours ago||

I just want a universal clipboard that works.

giancarlostoro 3 hours ago||

Copy and Paste too, and its because if you hit Ctrl + C (copy) by mistake, when you actually meant to hit CTRL+V did you know, that Teams, Discord, etc will copy a completely empty text-input box AND WIPE YOUR PASTE HISTORY WITH IT?

This is why copy and paste is broken for so many years, because devs at these beautiful companies, decided to let you wipe your end-user's clipboard when chatInputText.length === 0 or whatever. I noticed people having consistent issues with copy and paste when Teams became more prevalent, and it made no sense, until I realized.

If you work for one of these chat companies, for the love of GOD make an internal ticket, this is embarrassing.

thomastjeffery 5 hours ago||

Copy and cut are just redundant steps anyway. In Linux (generally), you can simply middle click to copy the current selection. Maybe we could add shift+middle click (or something) to do a move instead of copy.

The deeper underlying problem is that we treat arbitrary UI/UX implementations as objective truth. There is one decided way your computer can be interacted with, and you the user must accommodate it. This is what I want to change.

cyanydeez 4 hours ago||

first, _DONT_ overwrite standard behavior as default; opencode is doing this. When I get in the flow, it all breaks when I want to copy something and it claims it's copying, but no, it's in putty or whatever and it's just a damn line.

issue here: https://github.com/anomalyco/opencode/issues/13984

ALWAYS default to regular behavior unless it's something you know exactly is going to go correctly.

lloydatkinson 6 hours ago||

At first I thought this was going to be the widely reported problem where despite copying something many times it still won't be there in the clipboard. I've even developed a habit of CTRL+C-ing half a dozen times from Chrome just to ensure it really worked.

fellowniusmonk 7 hours ago|

Plain text is way harder than people think. Partly because the reflow rules change depending if you are making edits in front of or behind the cursor/point of action.

On anything structured that doesn't require re-flow this approach makes some sense.

Lists, Grids, etc, there are pro/cons but it makes sense.

In this case you ARE causing reflow, so content and format change at the same time.

With normal cut and paste the reflow happens at the point of attention, and the final state paste keeps your eye right at the point of action.

This jumping around stuff means you are doubley losing tracking if you paste below the cut point. This is effectively an out of bound focus shift. This has higher cognitive penalty because layout is no longer occurring in serial but in parallel in multiple places.

idempotence, types, rejection of global state, all of these "engineering" rules go out the window when you enter the realm of mereological nihilism that is text editing.

The best you can do it think of things as causal chains like some CRDTs do.