Ghost Cut – or why Cut and Paste is broken everywhere

https://ishmael.textualize.io/blog/ghost-cut/

by willm • 7 hours ago

107 75 7 hours ago

ishmael.textualize.io

tectec• 6 hours ago

I don't think I would like this. He mentions Excel does something similar and Excel is my least favourite app to cut/copy/paste in.

varispeed• 5 hours ago

Half of the time it doesn't work as well.

xnx• 6 hours ago

Seems complicated. Doesn't selecting, then drag-and-drop do what the author wants?

clircle• 5 hours ago

My first thought as well. drag-and-drop is also fantastically useful for data you cannot Cut (e.g., moving an email attachment from one draft message to another)

aarvin_roshin• 6 hours ago

This reminds me of File Explorer's cut behavior. It's a nice idea but the layout shift on paste is disorienting.

atq2119• 6 hours ago

I sort of see the point about undoing the changes to the clipboard, although it's not actually so simple. The clipboard is system-wide shared state -- what if another application changed the clipboard between the cut and the undo?

The other part of it ("ghosting" the cut) just seems like a matter of taste, and at some point you have to consider whether going against decades of established muscle memory in the users of your software is really worth it.

That said, it is a good idea to re-examine our assumptions every once in a while, so kudos for that.

nlawalker• 6 hours ago

This is what Windows Explorer does when you cut a file, except it does also place it on the clipboard.

pressing ctrl+x fades the selected text and makes it inert [...] Nothing is placed in the clipboard at this point
What if you want the original semantics of cut? Ghost cut makes that two keys rather than one: copy to clipboard (control-C or command-C) followed by Backspace to remove it from the original document. I so rarely use cut without paste, that this is a clear win for me.

This is just as "broken" as the existing functionality, just in a way that the author prefers. It's a neat idea though, I like it, makes you wonder what would have happened in other apps if cut/paste was never developed as a system-wide, cross-app capability.

Diogenesian• 5 hours ago

This reads to me as the default behavior of "cut" makes certain usability choices that don't gel with the author's personal mental model and workflow, which is of course totally valid. But it is odd to see things described as a "flaw" instead of a choice.

The most glaring example seems to be the first: typically an accidental cut was intended to be a copy, not a delete, so leaving the text in your clipboard is a sensible design. I understand the author's perspective, and maybe OSes should have configurable "cut." But I think most people understand "undo" as "undo change to file" and not "undo change to file + OS state." In that sense the default behavior is not a flaw.

Again - the author's points about an alternative cut are reasonable, but they seem to appeal to a minority of users.

VerifiedReports2• 5 hours ago

Yes, I disagree that the cited behavior is defective. But I respect his pointing-out of the shortcomings and offering other options.

I find myself using the clipboard-erasure "defect" somewhat frequently to cut something to the clipboard, and then undoing the change and using the clipboard contents. And this is specifically useful in a way that merely copying isn't... but at the moment I can't remember why, or whether I use this when programming or working around InDesign's many defects.

blt• 5 hours ago

It's really natural!

- make a bunch of edits

- decide I don't like all of them

- copy the part I want to keep

- undo a bunch

- paste the good part

This is copy, not cut, but it wouldn't work if the clipboard state was part of the undo system.

Wowfunhappy4• 5 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.

drdexebtjl3• 4 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.

Wowfunhappy4• 4 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.

0gs• 4 hours ago

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

justsomehnguy• 4 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.

Wowfunhappy4• 3 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?

fellowniusmonk• 5 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.

kps• 5 hours ago

Star didn't have cut/copy/paste. Instead it had ‘copy to’ and ‘move to’ operations on the current selection, more like today's drag-and-drop. Some influential people decided that invisible fragile clipboard state was better than a copy/move-in-progress state.

QuercusMax• 5 hours ago

Probably was seen as too modal. Modal UI was very unfashionable for a while.

applfanboysbgon• 17 minutes ago

As it should be. Modals are awful UX. The killer feature for me, for Obsidian and VSCode compared to eg. Notepad and Notepad++, is having a file explorer pane so you can create, open, move, save, and delete files without opening an explorer modal or tabbing to another window for every operation. It removes so much friction from common actions.

panic• 3 hours ago

A 2012 historical retrospective on the subject from Larry Tesler (the NOMODES man himself): https://www.lri.fr/~mbl/ENS/FundHCI/2013/papers/Tesler-CutCo...

The issue he had with the “move to” operation is that it forced you into a mode where you had to pick a destination right away. I wonder if OP’s proposal was ever brought up at the time—it does seem like a promising middle ground!

frenzcan• 5 hours ago

I think I have permanently broken my mental model of the clipboard. I’m always alternating between Linux, Mac and Windows and muscle memory invariably causes me to do the wrong key combo for the OS/app I’m using. Throw in clipboard sync/history tools etc which aren’t always reliable, I regularly paste and either nothing happens or it’s a previous copy of something. It sounds like a small thing but it’s maddening and mostly my own fault.

lloydatkinson• 5 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.

alehlopeh• 5 hours ago

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

cush2• 5 hours ago

Agree accidentally clobbering the clipboard is super annoying. Clipboard history apps are a godsend. Like Paste on Mac, or Windows has it built in.

Cockbrand2• 3 hours ago

The Mac now has a clipboard history as well, it's just a bit awkward. You can open Spotlight with ⌘Space, and within Spotlight open the clipboard manager with ⌘4.

david422• 3 hours ago

I used to use a 3rd party clipboard (until blocked by work) that used Cmd-Shift-V to bring up the clipboard. So much nicer than Apple's solution.

cush2• 2 hours ago

Ya that’s too awkward. Clipboard history needs to be ⌘+Shift+V or I’d never use it

30minAdayHN• 2 hours ago

I came here to exactly comment about this. I use Maccy and it is godsend. It is single most valuable productivity hack.

I first encountered clipboard history in Jetbrains Rubymine editor

bighead1• 5 hours ago

want to thank the author of that post for giving me the opportunity to be thankful that I get to live my life without ever having to deal with the consequences of their opinions.

imagine having that guy as your roommate!

replatformradar• 5 hours ago

Interesting take on such a simple action but such a frustrating one when it does not work they way you want.

akkartik• 5 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.

throwawayffffas• 5 hours ago

Cut and Paste is three operations.

Cut is two operations copy and delete, copy is never undone by undo it should not be undone when you cut either. I cut, undo, ..., undo, and paste multiple times a day. It's a feature not a bug.

Cut & Paste is not atomic

Yes because it's two different actions.

What does "Ghost Cut" do if you paste multiple times? Paste the cut text first and then what? The previous thing in your clipboard? Why does my editor need to read my clipboard if I am not pasting (to implement the rollback)? What if there was a secret key in there do we just hand it to copilot or whatever extension is running?

Cut is copy and delete plain and simple.

Cut and paste is a poor analogy in the file explorer, what the file explorer does is a move, "cutting" fills the first parameter and "pasting" fills the second. Hence the greying out and not doing anything until you paste. There is no clipboard for the filesystem. Also in the file browser it's extremely unlikely you would want to paste into multiple places, something not true in text editors.

EDIT:

Now listen I am not saying the proposed semantics are bad, to each their own, but it's a different operation all together the clipboard is not even required you could have a separate short cut that grays out the text and then moves it to where you want. The whole thing would be atomic called a move and be cleaner in all ways.

windward2• 4 hours ago

paste multiple times

Because you're trying to 'copy' it?

This feels baby-duck-y. No given mental model is more right than another. There's already not even a consistent model, because:

Cut is copy and delete

So copy and delete! Or, in Vim and Emacs, just delete!

arijun• 1 hour ago

Or, in Vim and Emacs, just delete!

Off topic, but that’s actually my biggest pet peeve vim. You copy text one place to overwrite some other text, you delete the existing text and they you go to paste and… the buffer has been overwritten. It makes so much more sense to require users to hit the obvious, composable ‘yd’ in the cases they want to copy than an arcane incantation in the cases they want to overwrite text.

Mogzol2• 4 hours ago

I cut, undo, ..., undo, and paste multiple times a day.

Why would you cut + undo as opposed to just copy? Are they not the same operation at that point?

sharkjacobs• 4 hours ago

I often cut + undo because seeing the cut is feedback which tells me the operation successfully put the content into clipboard. This is not always a guarantee especially in web apps, and sometimes I just have focus on the wrong window.

vjulian• 4 hours ago

I feel as though I’m reading the script to a Monty Python sketch.

croes• 4 hours ago

Have you never copied, tried to paste and you pasted the wrong thing because copy failed?

Cut + undo, is copy with visual feedback

the_lucifer• 1 hour ago

Cut and paste is a poor analogy in the file explorer, what the file explorer does is a move, "cutting" fills the first parameter and "pasting" fills the second. Hence the greying out and not doing anything until you paste. There is no clipboard for the filesystem. Also in the file browser it's extremely unlikely you would want to paste into multiple places, something not true in text editors.

Yep, which is why the dislike for macOS's finder workflow of copy a file: ⌘+C (irrespective of cut/move/copy) -> decide at destination: ⌘+⌥+V (move) or ⌘+V (paste) confuses me. It's the best intuition imo.

Weirdly, Windows does the same thing which doesn't garner enough hate as it also excludes the associated good UX. Cut fades a file out in the explorer (akin to this "Ghost cut" concept) then a paste moves it (so you don't end up losing files).

jerf• 4 hours ago

Cut and paste is broken everywhere because of the number of apps that think they know better and "fix" it.

My bitterness is compounded by being on Linux, where this is probably even more encouraged in GUI apps then in other OSes. But I still have enough independent arguments with web sites, on my phone, and even in the context of the same application at times to have valid complaints just based on those.

Clipboards don't get an independent undo dimension because most users can't handle it. They're pretty full up on dimensions. Clipboard managers at an OS level are the better solution for those who can than another app "fixing" the problem in some unique way.

dec0dedab0de• 4 hours ago

I wish the OSes wouldn't even expose to the applications anything about copy, cut, and paste. From the applications perspective it should be indistinguishable from any other io.

Towaway69• 4 hours ago

AFAIK, Chuck always used cut, undo, paste. I think he referred to copy & paste as being for script kiddies.

rickydroll• 4 hours ago

Cut and paste is a UI failure; it only works kinda if you have fully functional hands. If your hands don't work right, or you have tremors or other mobility impairments, your chances of succeeding with cut and paste drop off significantly.

The Emacs mark-and-point UI works for everyone: fully functional hands, partially functioning hands, or even speech recognition. It also solves the problem of copy, cut, and paste described in the article.

rpdillon• 4 hours ago

Reading through the post, it was clear that the author wasn't very familiar with Emacs. I'm a huge fan of the undo model of Emacs, especially with tools like undo-tree (although cycling through with M-y is basically as good for my use cases). The "replace the clipboard" bug doesn't exist because Emacs has a killring (I'm such a fan I bought killring.org years ago!), and the "text reflows" problem is completely solved use C-u C-space to traverse the mark-ring. His final point, that it is multiple operations, I simply disagree is a bug...multiple operations is fine, because I can compose them in a way that suits my workflow. Of course, in Emacs it would be trivial to write Ghost Cut (though it would only work within Emacs...).

delecti• 4 hours ago

This is an interesting perspective I had never really thought about, and I like the proposed new action, but I don't really want it in lieu of how cut/paste currently works.

In my mental model (which is also how OSs work, though not necessarily how things ought work), the clipboard exists at the OS level, and undo/redo act on the application level. I don't find it to be unexpected or undesirable that doing Ctrl+X,V,Z,Z results in the application returning to its original state but the clipboard ending up being modified.

All that said, I appreciate that this interrogated my mental model a bit.

aykutulis• 3 hours ago

Most of the time I use "cmd + x" to delete the whole line during coding. So ghost cut conflicts with my habit. I don't think it is a good habit but it is what I got used to. I've also seen people with the same habit. So it might be a good time to change my habit

layer8• 3 hours ago

anything more than you are doing already. I call it "Ghost Cut", and it works like this: pressing ctrl+x fades the selected text and makes it inert—you can't click on the cut text and the cursor just kind of leaps over it, but it is still present in the document. Nothing is placed in the clipboard at this point and there is nothing to undo. If you decide you don't want to paste then hitting escape will restore the text to its active editable state.

What if you press Ctrl+X twice on separate regions and then press Escape (once)? Does it restore the state after the first Ctrl+X? So Ctrl+X pushes on a to-be-cut stack and Escape pops? Probably not.

Anyway, this looks like it means that the inability to undo the change in clipboard state is replaced by the inability to return to an earlier to-be-cut state. Or maybe the editor includes a Vim-like time-travel history that includes the to-be-cut state?

Regarding the clipboard state, given that the clipboard is an OS-level object, for me it makes sense that an application-level or document-level undo doesn’t undo changes in the OS object. Similarly, undo after Save doesn’t undo the change in the file system state. Of course, it’s fine to provide alternative editing operations in addition.

Cockbrand2• 3 hours ago

The Finder has an interesting take on this: copy a file with ⌘C, then move it somewhere with ⌥⌘V. This is much nicer than the Windows Explorer's CTRL+X and CTRL+V, where the user is unsure what happens when they never paste the file.

Cyberdog• 2 hours ago

What does happen if you never paste the file?

It feels to me like cut/copy (in the clipboard manipulation sense)/paste are nonsensical operations on files in the first place.

thomastjeffery• 3 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.

overgard• 3 hours ago

I really like this, but I think I'd be confused if I saw this without context -- the current behavior is so ingrained in me that any deviation would kind of be a wtf. Not unrecoverable but I think it's hard to change something so widespread.

trgn• 2 hours ago

I consider myself reasonably competent, reached conventional milestones in a career in tech, did a thing here and there, and I'm reading this, sort of nodding along, and barely understand what's the issue again with cut&paste, there was one, which one ?, anyway, middle age you guys, it's real.

cyanydeez• 2 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.

Y444• 2 hours ago

hitting escape will restore the text to its active editable state

This is the fatal flow of the whole thing, with this it stops being a drop-in replacement.

giancarlostoro• 2 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.

theowaway• 2 hours ago

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

foo12bar• 1 hour ago

What I'd like seen addressed is the insistence of every app trying it's best to include formatting information, even so far as to include table cells formatting data in the clipboard. I've found copying this format info useful maybe twice(?) in my 50+ year life and otherwise it is a huge PITA. Including having email clients crash or refuse to properly undo weird table formats that unintentionally get pasted over. Instead, I have to paste to an open editor in a terminal window and then do another copy and paste to the destination to most reliably disable this.

ryandrake• 18 minutes ago

Some applications provide a "paste without formatting" that is distinct from "paste" but often that one removes things like hyperlinks, which you generally want to keep.

The "paste" idiom has been thoroughly stressed to the limit. Should "paste" paste just text? Should it include text color? Should it in crude text background color? Should it include typeface? Should it include text size? Should it include attached metadata like hyperlinks? Should it include other stuff around and peripheral to the text?

tibbydudeza• 1 hour ago

I just want a universal clipboard that works.

wasabi991011• 1 hour ago

"Ghost cut" _does_ exist in VSCode, Word, GDocs, etc., it's called a move and you do it by dragging selected text with your mouse.

abanana• 42 minutes ago

Please don't change expected behaviour!

Excel does, as the author mentions, and it's a massive pain in the arse because it doesn't do what it should.

The "cut" action is supposed to immediately put it into the clipboard, so you can paste that text into other programs if you want to.

Thinking you know better, is really not a reason to break your users' expectations and normal workflow. It's quite possible your idea is a good one, but it's not worth breaking it for the majority, to improve it for a few.

gwbas1c• 38 minutes ago

This is similar to how Explorer / Finder handle cut: The file isn't moved until paste.

EPWN3D• 33 minutes ago

I don't think I've ever had a problem with this. The big problem I've had with cut/copy/paste has been with Windows and software inspired by it, which is that copying without selecting any text blows away the clipboard (because you've chosen to cut or copy the empty string).

Like yes, I get that in a strict engineering sense, that is the correct and least surprising behavior. But it's stupid and virtually guaranteed to not be what I wanted to happen. My expectation is what macOS does in this event -- nothing.

jimjimjim• 10 minutes ago

Cut and Paste isn't broken, Copy is broken (in windows). My muscle memory for copying and pasting text is now: ctrl-c, ctrl-c, ctrl-c, ctrl-v.

Ghost Cut – or why Cut and Paste is broken everywhere

Related Stories