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.
I agree with TFA on all points and therefore strongly disagree with all that is said in this post. "Cut'n paste" should be one atomic operation. If you want to do multiple pastes (why? what's the context?) then copy to the clipboard and paste to your heart's content.
It's also a fundamental flaw that undoing cut doesn't undo its side effects. Undo should always mean: restore the state of the world (/of the system) to where it was before. Not just "back up a few steps depending on this or that".
> If you want to do multiple pastes (why? what's the context?)
Remove a piece of data from one place and place it in multiple others.
While I empathise with the desire for an atomic operation for moving text, the cut semantics have solidified to the current experience for many years. Additionally no undo or redo operation in text editors ever modifies the clipboard, if I copy and undo the clipboard will keep the copied text. Similarly if I cut undo copy another piece of text and then redo, the clipboard will maintain the text copied, before the redo not the cut text.
Undo and redo on the clipboard is a very foreign idea to how text editing has been done by billions of people over decades.
An atomic move operation would be nice, but it needs to not change the semantics of existing operations, and implementation wise does not need to involve the clipboard at all.
> Undo should always mean: restore the state of the world (/of the system) to where it was before.
So if you copy and undo you want clipboard restored instead of undoing the previous app action???
Or should it maybe undo the mouse movement? Or text cursor movement? "State of the world" was the cursor in a different place after all
Such "absolutist" approach won't help you design a good system as that "always" depends on many different specifics
Well, in fact a good principle is to limit side effects as much as possible. Copy or cut inside the same document should probably not involve the system clipboard at all. The system clipboard could be triggered/populated when the app goes out of focus for example.
Maybe internal registers are the primary way, though that prevents some niche cases like clipboard watchers (copied #hex color to clipboard, have an option to insert any other format).
One reason to stop there is because your examples are absurd, while mine aren't. The are already apps where you have undo stacks for selection and text cursor positioning, so coupling that with the "state of the world" is an option. But unfortunately absurdity doesn't offer any guidance just like shallow absolutes. Think harder
> 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).
I dunno, in my preferred text editor (joe), i set up a selection, and I can delete it if I want, or go where I want it and do copy or move the selected region.
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.
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.
Copy and paste gives you visual feedback without reflowing the document. I also use it to intentionally add a marker in undo history in documents in not planning to change, as that way I can use the undo history to jump to different areas.
The paste action gives you feedback by having the cursor move to the end of the selected text after it replaces the text you copied with itself.
If you're on Android, lately it actually does give feedback by putting the copied text into the predictive text/autocomplete bar above the keyboard (I find this annoying as I'm usually copying text to save for later use, and I use the appearance of text I want in the corrections as an indication I've swiped wrong. If only I could touch-type while lying down...). In other apps that don't display the keyboard, it sometimes gives you a toast that an app has access the clipboard, though it gives the same toast for pasting or just for accessing it (eg pasting with termux or using an RDP app that syncs the clipboard)
In Linux, if under XFCE, strangely by default, Clipman keeps a log of all text ever copied, in a giant textsrc file ( .cache/xfce4/clipman/textsrc )
That is kind of the opposite though, and more of a passive, almost furtive, indelible clipboard feedback. I was pretty astonished to find it, hovering somewhere near 4MB with years of content.
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.
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.
The article isn't arguing that clipboard state should be part of the undo system, it is arguing that cut shouldn't touch clipboard state. In the "Side effects" section they mention if you want the contents to go to the clipboard, then you should use copy instead of cut.
Agreed, I like being able to cut or copy text into the clipboard, undo a few recent edits (Ctrl/Cmd+Z), then paste the contents of the clipboard in a new spot. The author's proposal would prevent me from doing that, at least without adding intermediate steps like pasting the clipboard into a temp file before undoing.
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.
The Excel workflow is surprising from the viewpoint of consistency with the OS but works pretty well for Excel users. Cut, paste multiple times, enter for the last one. I notice the multiple paste doesn't work on Excel on the Web.
The clipboard is very weak in Excel. If I copy something, update a cell somewhere and then paste elsewhere, the clipboard vanishes and I need to copy all over again.
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.
It's quite a different mental model the author has from me.
Cut moves text from the application into a separate application, the clipboard.
So just like if I edit in application A, change to application B and hit undo, I do not expect undo to affect A, I also do not expect undo to affect the pasteboard.
The Ghost Cut works a bit closer to how Excel works, which constantly trips me up. In Excel, I might copy a cell, do some edits, then paste, only to learn that nothing was actually copied. In Excel, copy and cut makes a reference to a selection, and if that selection has been undone or changed at the time of paste, there simply isn't anything to paste.
"Ghost cut" is basically how Excel has always done cut&paste, I think maybe without involving the clipboard at all.
Looks like there are two different expectations of cut&paste. Most software seem to treat it as simply a copy&paste with a "delete" action tacked on, while the author (and Excel) treat it as "move content around inside the document".
I get the author and the frustrating undo behavior but I'd also like to add that Ghost Cut is less flexible than the "traditional" cut&paste interpretation: Ghost Cut expects me to always have exactly one location where I want to move the content and expects that this location is in the same program or even in the same document. Traditional cut&paste doesn't have those limitations.
On the other hand, if traditional cut&paste is just glorified copy&paste anyway, I think not much would be lost by replacing it with the Ghost Cut interpretation - people can still get the "traditional" behavior by doing a copy and then pressing backspace...
Have to disagree here. I think Excel is amazingly well engineered, and very well designed for the majority of the users, despite some flaws.
Excel is a bit complicated for cut/copy/paste, because you have not only the content of the cells, but also references to cells. Cut and copy have subtly different behaviour that, I think, works well for most people's mental model.
Namely: Most instances of cut are followed by one paste, and really constitute an atomic move. That's why when you cut and paste something in Excel elsewhere, all references to cells that have been moved are updated, no matter whether they were inside the moved area or outside, and no matter whether they were relative or absolute. (Just the same as they're naturally updated if you insert or delete columns/rows above or to the left of the referenced cell).
That's why a cut "marks" the cut cells, and after you paste, nothing is marked anymore. You can't paste twice. It's akin to the Ghost Cut described in the article: an atomic move that only happens upon paste.
When you copy, however, and paste somewhere else, a) only the "relative" references among the moved cells are updated (neither absolute references nor references in cells that were not copied are updated); and b) the copied area remains "marked" and you can paste again and again.
Given the complexity of this (think about references that are ranges...), a) it's a wonder that it works as well as it does, doing the expected thing for most people most of the time, and b) it's understandable that you can't cut or copy, then modify the marked origin (it'll unmark the cells and abort the operation), then paste.
This means, incidentally, that a copy & delete in Excel is distinct from a cut.
You can't work well for a "mental model" based on frequency because in reality you have two different mental models. Sure, if one is more prevalent you might reduce the frequency of a mismatch, but that's it.
> doing the expected thing for most people most of the time
because regular cut and paste breaks all the formulas that reference where I'm pasting into. They should have kept normal cut-and-paste and made Ctrl+Shift+(plus) do their special paste.
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.
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.
Hyperbolic title is, unsurprisingly, misleading. At least the article follows the style consistently.
The "ghost cut" is a two-step text move. A perfectly fine operation to have, _because_ it's not the same as a cut operation followed by a single paste operation.
Cut can be used without paste, and paste can be used more than once. They're combinable primitive operations. Sometimes what you want isn't that combination. Someones it is. But claiming that they're _broken_ ... is not a sign of someone who's able to see past their own needs and preferences.
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.
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.
Don't modern clipboard managers like Ditto already solve this issue because they have non-destructive clipboard history that's instantly viewable and searchable? They also open up the entire feature space because they can have multiple clipboard buffers. Also, it's a user option whether pasting from the history moves the pasted item back to the top or leaves it where it was
Personally, I have a hotkey set up just for pasting the second-to-last thing I cut or copied (Ctrl+Alt+V). This is handy for when I want to swap two things. Ctrl+Alt+(1 thru 0) will paste the last 1 thru 10 history entries.
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.
>after a cut restores the text to its pre-cut state in the document, but changes to the clipboard remain.
which is exactly how it is supposed to work. why would I want previous state ? Why I'd even remember that state ?
> If you regret replacing your clipboard contents then too bad, they have gone poof in the digital ether.
Clipboard managers have been a thing since clipboards. Tho it would be nice to have one integrated, say so I can get menu of previous pastes with search and paste it in one step instead of "select what's in clipboard, then use it as normal" as it is with most
> 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.
Well unless you're pasting in exact same spot, how else would it work ? Editor doesn't even know if you want to paste it back into same document
> Undoing a paste will remove the newly added text, but it requires a second undo to completely restore the text—assuming there weren't any edits between the cut and paste.
that is because you might've pasted it in wrong space.
Sometimes the simple thing is better, because you can encode its way of working in your way of working without wondering 'oh why my pasted text was copied from'
This person is free to think this, but I don't think I agree.
Personally I'd prefer something to be done about cut/copy-jacking where you try to copy a highlighted item and your site or application decides to copy something entirely different in an effort to be 'helpful'.
If I'm copying a url, I don't want my browser prefixing it with https:// for example.
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.
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.
> If you decide you don't want to paste then hitting escape will restore the text to its active editable state.
That's unergonomic, you should move your whole hang of your regular positioning because you can't use the convenient Ctrl+Z?
This also breaks cut and paste across apps because now you have different mechanics depending on context.
Might be better to preserve everything, but maybe have an option to visually preserve the text until time has passed or other action? (Paste, typing, etc)
1. That's the issue with clipboard management. Given the transient nature of clipboard, while I do appreciate having the opportunity to preserve the pre-cut values, it's not that often that I need it, so I'd definitely not pollute my app actions undo stack with an extra step (yes, the author doesn't do that either)
And you can improve your app by storing the pre-cut clipboard and allowing easy restore
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.
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?
Table cells or even highlighted bits in a larger copy are often enough useful but they should at the very least strip the styling that applies to the whole text because in 99.99% of cases I want that to match where I'm pasting to.
Ghost cut looks like a good idea to deal with an issue OP has :
- I located where I want my text to go
- but when I select and cut, it reflows and I need to locate the place again
Considering the millions of edge cases with Copy, Cut & Paste, the best idea seems to use two other keys for Ghost Cut and Ghost Paste.
And Ghost Paste would put it into the clipboard so that you can paste it multiple times and in other apps.
I've another idea of how to do the Ghost thing :
- locate where the text has to go, mark the location
- select and cut the text, the editor reflows
- go back to the marked location then paste
the editor may have built-in bookmark key shortcuts, or it would be a new thing to create.
> 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.
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.
It always annoys me when on Windows (often accidentally) selecting something replaces what I explicitly Ctr+C'd because there are no separate clipboards.
It has an obvious precedent in using cut and paste for moving files in a GUI file manager. When you cut a file, it doesn't disappear, but may be marked somehow (e.g. grayed out) as being the source of a move; it disappears from its original location when the move is completed.
I'm a bit confused about this. As in: how is what cut and paste does right now exactly problematic? And: how does this perform with assistive technologies? Text that is faded out or even invisible visually more often than not is still detectable by assistive technology because it is in the accessibility tree. (This also is what makes certain kinds of websites which try to look "fancy and clean" but in actuality have 6-10 panels all on one page which appear and disappear as you do things extremely hard to use by people with screen readers: the screen reader sees all of the different UI elements, even if completely invisible.) Does this "alteration" remove the "cut" text from the accessibility tree or does it remain? If so, this "fading out" of the region will appear to do absolutely nothing and will confuse disabled users if this feature were to get remade like this.
It's called cut and paste (2 actions), not "move" or otherwise. Being consistent with decades of software usage is more important that whatever you think is "broken" or not, because that's not actually the case, just another model of how to do things. The Excel example is particularly interesting, Excel does something similar, so when you "cut" ("ghost" version) and paste in a cell that overlaps with the range being cut, it breaks completely, which it wouldn't if it did the simple "remove cells, put them somewhere in memory, paste them to new location".
If I "Ghost Cut" from one application and paste into another, what is pasted? the last thing that was in my clipboard or the ghost cut text? And if I undo in the second application, is the text restored in the first one?
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.
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!
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.
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.
Same frustration applies to file converters — the UX is almost universally broken. Most tools silently upload your files to S3 while showing a spinning wheel, then email you a link. The File System Access API has made it possible to do this properly in-browser now, but almost nobody uses it.
I'd be happy if things stopped interfering with standard X11 select/paste. It's now a random crap shoot if I have to hold Shift or not to regain that elegance.
And, the whole idea of copy/paste having to use both mouse AND keyboard (select Ctrl-c click Ctrl-v) is barbaric. X11 got it right and it seems all "modern" apps are trying really hard to introduce barbarisms.
I think this is a reasonable set of objections to how cut and paste works if you were designing it from scratch. I'm not saying I agree with the conclusions, cut AND paste, is 2 operations so it seems silly to say you can undo both with 1 undo. It's kind of a RISC/CISC thing, is your opcode CUTANDPASTE or CUT and PASTE?
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.
I guess they've never heard of select-and-drag? Which isn't universal, but is common. And should be universal. I use it frequently. So many one-time-password forms break it in various ways, like wanting the value to go into six separate input boxes (why is this so common!?).
It's an interesting thought, but hard to imagine how this would be implemented system wide. The clipboard would need to remember the source application, and have some kind of unique identifier to issue a delete to the source application.
This looks so logical my mind struggles to understand why this is not how it already works in other programs o.O
the points on how undo interacts with this and the clipboard contents its also a good example of how relatively simple features can have a fairly high combined complexity to ensure the features do behave as expected if you use them in tandem.
nice writeup and cool solution :) thanks!
i see some comments about the move, and the cut & paste to be 3 actions etc. this is perhaps technically the case in current programs that you use, but conceptually and for most non-tech users this is not how the feature is presented. hence i think its a nice solution to fit the behavior to how its presented, rather than presenting more different ways to manipulate the document, using a move or other methods. (this would add complexity for non techy users. many editors which are mentioned are very complex with lots of keybindings)
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
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.
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.
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)
Is there any kind of solution to saving everything that is cut or copied to some kind of temporary history so you can paste things you copied/cut like an hour 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.
The mouse-driven EMACS I used in the 90s had a text swap feature that was so elegant - highlight one word, double-click another word, and boom - they swap places.
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.
Oh if only cut and paste was broken... In Windows and Linux copy and paste itself is broken. Sometimes you copy with mouse, sometimes you copy with keyboard, and if it is a recent version of MS Office likely neither will work. Sometimes you paste with Ctrl+v sometimes with Ctrl+shift+v, sometimes with mouse, sometimes it just won't work. Such a simple operation should have been completely owned by the OS.
It works very reasonable on Linux/X11 with two separate clipboards - one for Ctrl+C/V and one for selection / middle click paste.
Ctrl+Shift+C/V is only necessary for terminals that already have other historical pre-GUI conventions for the Ctrl+ combinations - and you can always use a terminal emulator that lets you use Ctrl+C/V with the GUI semantics.
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.
> 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.
...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.
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.
> 2. Cut reflows
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. A tiny cognitive burden perhaps, but I'd argue an unnecessary one.
This is ridiculous. When I cut something in real life I expect it to be gone. Of course it reflows after that operation.
I don’t have a problem with this new operation but “redirect” is probably a better name, and not even a perfect one, compared to “Ghost Cut”
Cutting means removing, hence “being cut from the team”. This author is either having a hard time with English or being bombastic to try and sell their idea.
Cut & Paste always struck me as more of a Windows thing. Which is weird because obviously I can do cmd+X / cmd+V on a mac... I just never do. Instead it's "select" - command+C - delete - cmd+V.
Am I the only one who does that?
(EDIT: Same thing on Finder. cmd+C cmd+Del cmd+V)
Anyway, I love the design aesthetic of the site, and when people question existing paradigms. Will definitely be checking Ishmael out.
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.
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.
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...).
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.
It’s not unreasonable to suggest that text editors need a nice atomic move (but personally I don’t see the need for it)
in most editors you can just select text and drag it around with the mouse
I agree with TFA on all points and therefore strongly disagree with all that is said in this post. "Cut'n paste" should be one atomic operation. If you want to do multiple pastes (why? what's the context?) then copy to the clipboard and paste to your heart's content.
It's also a fundamental flaw that undoing cut doesn't undo its side effects. Undo should always mean: restore the state of the world (/of the system) to where it was before. Not just "back up a few steps depending on this or that".
> If you want to do multiple pastes (why? what's the context?)
Remove a piece of data from one place and place it in multiple others.
While I empathise with the desire for an atomic operation for moving text, the cut semantics have solidified to the current experience for many years. Additionally no undo or redo operation in text editors ever modifies the clipboard, if I copy and undo the clipboard will keep the copied text. Similarly if I cut undo copy another piece of text and then redo, the clipboard will maintain the text copied, before the redo not the cut text.
Undo and redo on the clipboard is a very foreign idea to how text editing has been done by billions of people over decades.
An atomic move operation would be nice, but it needs to not change the semantics of existing operations, and implementation wise does not need to involve the clipboard at all.
> Undo should always mean: restore the state of the world (/of the system) to where it was before.
So if you copy and undo you want clipboard restored instead of undoing the previous app action??? Or should it maybe undo the mouse movement? Or text cursor movement? "State of the world" was the cursor in a different place after all
Such "absolutist" approach won't help you design a good system as that "always" depends on many different specifics
Well, in fact a good principle is to limit side effects as much as possible. Copy or cut inside the same document should probably not involve the system clipboard at all. The system clipboard could be triggered/populated when the app goes out of focus for example.
Maybe internal registers are the primary way, though that prevents some niche cases like clipboard watchers (copied #hex color to clipboard, have an option to insert any other format).
Why stop there, move back the clock as well. And send requests to all the remote hosts to send our packets back.
One reason to stop there is because your examples are absurd, while mine aren't. The are already apps where you have undo stacks for selection and text cursor positioning, so coupling that with the "state of the world" is an option. But unfortunately absurdity doesn't offer any guidance just like shallow absolutes. Think harder
> 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).
I dunno, in my preferred text editor (joe), i set up a selection, and I can delete it if I want, or go where I want it and do copy or move the selected region.
> you could have a separate short cut that grays out the text and then moves it to where you want.
That's basically drag & drop (on macOS).
>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!
> 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.
Spending enough time drinking the kool aid means I know at least 3 ways to use registers to avoid that, and practically end up using none of them
_d
D
_dd
> 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?
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.
How can you be sure that the undo stack is in sync with the clipboard? Wouldn't cut+paste be a more reliable pseudo-copy than cut+undo?
> How can you be sure that the undo stack is in sync with the clipboard?
Simple: they're not meant to be. Undo stack and clipboard are orthogonal. It's like foundational rule of computing.
Have you used a clipboard manager? There are tons that you can configure with notifications and indicators, so you don't have to that.
Having to install yet more software seems worse than the problem you’re suggesting it should solve.
Even windows has this software out of the box because it is so obviously useful
At least it would save you a keystroke every time, if it enables you to switch from cut+undo to copy.
I feel as though I’m reading the script to a Monty Python sketch.
Have you never copied, tried to paste and you pasted the wrong thing because copy failed?
Cut + undo, is copy with visual feedback
Copy and paste gives you visual feedback without reflowing the document. I also use it to intentionally add a marker in undo history in documents in not planning to change, as that way I can use the undo history to jump to different areas.
Where does Copy give you feedback that you actually copied something?
The paste action gives you feedback by having the cursor move to the end of the selected text after it replaces the text you copied with itself.
If you're on Android, lately it actually does give feedback by putting the copied text into the predictive text/autocomplete bar above the keyboard (I find this annoying as I'm usually copying text to save for later use, and I use the appearance of text I want in the corrections as an indication I've swiped wrong. If only I could touch-type while lying down...). In other apps that don't display the keyboard, it sometimes gives you a toast that an app has access the clipboard, though it gives the same toast for pasting or just for accessing it (eg pasting with termux or using an RDP app that syncs the clipboard)
That’s too late, if copy didn’t work or I copied the wrong part I have to go all the way back and select the part to copy again.
That’s why Ctrl-X, Ctrl-Z is the way
In Linux, if under XFCE, strangely by default, Clipman keeps a log of all text ever copied, in a giant textsrc file ( .cache/xfce4/clipman/textsrc )
That is kind of the opposite though, and more of a passive, almost furtive, indelible clipboard feedback. I was pretty astonished to find it, hovering somewhere near 4MB with years of content.
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.
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.
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.
The article isn't arguing that clipboard state should be part of the undo system, it is arguing that cut shouldn't touch clipboard state. In the "Side effects" section they mention if you want the contents to go to the clipboard, then you should use copy instead of cut.
If it doesn't change the state how do I cut and paste between programs? And is 'paste' now using the clipboard half the time but not the other half?
Yes exactly, cut (and pasting a cut) is entirely within the same app. If you want to put something in another program you would have to copy.
Not saying I would prefer it, just explaining what the article says.
Exactly, you've nailed it.
Agreed, I like being able to cut or copy text into the clipboard, undo a few recent edits (Ctrl/Cmd+Z), then paste the contents of the clipboard in a new spot. The author's proposal would prevent me from doing that, at least without adding intermediate steps like pasting the clipboard into a temp file before undoing.
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.
Exactly.
You also open the gates to many edge cases where I don't know what it is supposed to happen.
What if I never paste the cut text? Does it stay faded?
What if I copy some other text, maybe on another app, before pasting? Do I paste the faded text or the new copied one?
Also, as you mention, I hate that you can't paste on a different program given the fact that the clipboard is untouched when you press ctrl-x
The gain is so minimal for a lot of headaches if you don't follow the happy path
The Excel workflow is surprising from the viewpoint of consistency with the OS but works pretty well for Excel users. Cut, paste multiple times, enter for the last one. I notice the multiple paste doesn't work on Excel on the Web.
The clipboard is very weak in Excel. If I copy something, update a cell somewhere and then paste elsewhere, the clipboard vanishes and I need to copy all over again.
But excel cells are not simply text: it is a different format, I don't have specific existing behavior for that.
It is very different with plaintext
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.
It's quite a different mental model the author has from me.
Cut moves text from the application into a separate application, the clipboard.
So just like if I edit in application A, change to application B and hit undo, I do not expect undo to affect A, I also do not expect undo to affect the pasteboard.
The Ghost Cut works a bit closer to how Excel works, which constantly trips me up. In Excel, I might copy a cell, do some edits, then paste, only to learn that nothing was actually copied. In Excel, copy and cut makes a reference to a selection, and if that selection has been undone or changed at the time of paste, there simply isn't anything to paste.
"Ghost cut" is basically how Excel has always done cut&paste, I think maybe without involving the clipboard at all.
Looks like there are two different expectations of cut&paste. Most software seem to treat it as simply a copy&paste with a "delete" action tacked on, while the author (and Excel) treat it as "move content around inside the document".
I get the author and the frustrating undo behavior but I'd also like to add that Ghost Cut is less flexible than the "traditional" cut&paste interpretation: Ghost Cut expects me to always have exactly one location where I want to move the content and expects that this location is in the same program or even in the same document. Traditional cut&paste doesn't have those limitations.
On the other hand, if traditional cut&paste is just glorified copy&paste anyway, I think not much would be lost by replacing it with the Ghost Cut interpretation - people can still get the "traditional" behavior by doing a copy and then pressing backspace...
I very often use cut&paste as "delete line" in IDEs by placing cursors anywhere on the target line without selection area.
Winthout selection area, most IDEs cut the whole line. That shortcut is very close to left hand anduch easier than any other way.
Ghost cut would butcher this usecase.
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.
Yeah I feel like Excel always thinks of what would be the worst way to copy/cut/paste depending on my intentions, and then it does exactly that.
I know that’s obviously not the case, but Excel is just so unintuitive in so many ways (for me).
Have to disagree here. I think Excel is amazingly well engineered, and very well designed for the majority of the users, despite some flaws.
Excel is a bit complicated for cut/copy/paste, because you have not only the content of the cells, but also references to cells. Cut and copy have subtly different behaviour that, I think, works well for most people's mental model.
Namely: Most instances of cut are followed by one paste, and really constitute an atomic move. That's why when you cut and paste something in Excel elsewhere, all references to cells that have been moved are updated, no matter whether they were inside the moved area or outside, and no matter whether they were relative or absolute. (Just the same as they're naturally updated if you insert or delete columns/rows above or to the left of the referenced cell).
That's why a cut "marks" the cut cells, and after you paste, nothing is marked anymore. You can't paste twice. It's akin to the Ghost Cut described in the article: an atomic move that only happens upon paste.
When you copy, however, and paste somewhere else, a) only the "relative" references among the moved cells are updated (neither absolute references nor references in cells that were not copied are updated); and b) the copied area remains "marked" and you can paste again and again.
Given the complexity of this (think about references that are ranges...), a) it's a wonder that it works as well as it does, doing the expected thing for most people most of the time, and b) it's understandable that you can't cut or copy, then modify the marked origin (it'll unmark the cells and abort the operation), then paste.
This means, incidentally, that a copy & delete in Excel is distinct from a cut.
You can't work well for a "mental model" based on frequency because in reality you have two different mental models. Sure, if one is more prevalent you might reduce the frequency of a mismatch, but that's it.
> doing the expected thing for most people most of the time
citation needed.
My Excel cut-and-paste workflow is:
* Copy the text
* Paste the text
* Go back and delete the copied text
because regular cut and paste breaks all the formulas that reference where I'm pasting into. They should have kept normal cut-and-paste and made Ctrl+Shift+(plus) do their special paste.
Half of the time it doesn't work as well.
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.
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.
Hyperbolic title is, unsurprisingly, misleading. At least the article follows the style consistently.
The "ghost cut" is a two-step text move. A perfectly fine operation to have, _because_ it's not the same as a cut operation followed by a single paste operation.
Cut can be used without paste, and paste can be used more than once. They're combinable primitive operations. Sometimes what you want isn't that combination. Someones it is. But claiming that they're _broken_ ... is not a sign of someone who's able to see past their own needs and preferences.
> paste can be used more than once
Not in Excel after you cut. Because there, cut & paste is seen as an atomic move, akin to what's described in the article.
It always amazes me the things that other people get really amped up about. I've never in my life felt anything at all about cut and paste.
Well, it's useful. When the iPhone initially didn't support it, people were unhappy, and it was added soon enough.
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.
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.
Don't modern clipboard managers like Ditto already solve this issue because they have non-destructive clipboard history that's instantly viewable and searchable? They also open up the entire feature space because they can have multiple clipboard buffers. Also, it's a user option whether pasting from the history moves the pasted item back to the top or leaves it where it was
Personally, I have a hotkey set up just for pasting the second-to-last thing I cut or copied (Ctrl+Alt+V). This is handy for when I want to swap two things. Ctrl+Alt+(1 thru 0) will paste the last 1 thru 10 history entries.
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.
>after a cut restores the text to its pre-cut state in the document, but changes to the clipboard remain.
which is exactly how it is supposed to work. why would I want previous state ? Why I'd even remember that state ?
> If you regret replacing your clipboard contents then too bad, they have gone poof in the digital ether.
Clipboard managers have been a thing since clipboards. Tho it would be nice to have one integrated, say so I can get menu of previous pastes with search and paste it in one step instead of "select what's in clipboard, then use it as normal" as it is with most
> 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.
Well unless you're pasting in exact same spot, how else would it work ? Editor doesn't even know if you want to paste it back into same document
> Undoing a paste will remove the newly added text, but it requires a second undo to completely restore the text—assuming there weren't any edits between the cut and paste.
that is because you might've pasted it in wrong space.
Sometimes the simple thing is better, because you can encode its way of working in your way of working without wondering 'oh why my pasted text was copied from'
This person is free to think this, but I don't think I agree.
Personally I'd prefer something to be done about cut/copy-jacking where you try to copy a highlighted item and your site or application decides to copy something entirely different in an effort to be 'helpful'.
If I'm copying a url, I don't want my browser prefixing it with https:// for example.
"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.
aka "drag & drop".
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!
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.
> If you decide you don't want to paste then hitting escape will restore the text to its active editable state.
That's unergonomic, you should move your whole hang of your regular positioning because you can't use the convenient Ctrl+Z?
This also breaks cut and paste across apps because now you have different mechanics depending on context.
Might be better to preserve everything, but maybe have an option to visually preserve the text until time has passed or other action? (Paste, typing, etc)
1. That's the issue with clipboard management. Given the transient nature of clipboard, while I do appreciate having the opportunity to preserve the pre-cut values, it's not that often that I need it, so I'd definitely not pollute my app actions undo stack with an extra step (yes, the author doesn't do that either) And you can improve your app by storing the pre-cut clipboard and allowing easy restore
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.
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?
"paste as markdown" would be interesting but no I don't actually want to keep hyperlinks when I'm pasting without formatting.
Table cells or even highlighted bits in a larger copy are often enough useful but they should at the very least strip the styling that applies to the whole text because in 99.99% of cases I want that to match where I'm pasting to.
Ghost cut looks like a good idea to deal with an issue OP has :
- I located where I want my text to go
- but when I select and cut, it reflows and I need to locate the place again
Considering the millions of edge cases with Copy, Cut & Paste, the best idea seems to use two other keys for Ghost Cut and Ghost Paste. And Ghost Paste would put it into the clipboard so that you can paste it multiple times and in other apps.
I've another idea of how to do the Ghost thing :
- locate where the text has to go, mark the location
- select and cut the text, the editor reflows
- go back to the marked location then paste
the editor may have built-in bookmark key shortcuts, or it would be a new thing to create.
> 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.
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.
It always annoys me when on Windows (often accidentally) selecting something replaces what I explicitly Ctr+C'd because there are no separate clipboards.
> This is not without precedent.
It has an obvious precedent in using cut and paste for moving files in a GUI file manager. When you cut a file, it doesn't disappear, but may be marked somehow (e.g. grayed out) as being the source of a move; it disappears from its original location when the move is completed.
I'm a bit confused about this. As in: how is what cut and paste does right now exactly problematic? And: how does this perform with assistive technologies? Text that is faded out or even invisible visually more often than not is still detectable by assistive technology because it is in the accessibility tree. (This also is what makes certain kinds of websites which try to look "fancy and clean" but in actuality have 6-10 panels all on one page which appear and disappear as you do things extremely hard to use by people with screen readers: the screen reader sees all of the different UI elements, even if completely invisible.) Does this "alteration" remove the "cut" text from the accessibility tree or does it remain? If so, this "fading out" of the region will appear to do absolutely nothing and will confuse disabled users if this feature were to get remade like this.
It's called cut and paste (2 actions), not "move" or otherwise. Being consistent with decades of software usage is more important that whatever you think is "broken" or not, because that's not actually the case, just another model of how to do things. The Excel example is particularly interesting, Excel does something similar, so when you "cut" ("ghost" version) and paste in a cell that overlaps with the range being cut, it breaks completely, which it wouldn't if it did the simple "remove cells, put them somewhere in memory, paste them to new location".
If I "Ghost Cut" from one application and paste into another, what is pasted? the last thing that was in my clipboard or the ghost cut text? And if I undo in the second application, is the text restored in the first one?
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.
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!
Probably was seen as too modal. Modal UI was very unfashionable for a while.
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.
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.
Same frustration applies to file converters — the UX is almost universally broken. Most tools silently upload your files to S3 while showing a spinning wheel, then email you a link. The File System Access API has made it possible to do this properly in-browser now, but almost nobody uses it.
I'd be happy if things stopped interfering with standard X11 select/paste. It's now a random crap shoot if I have to hold Shift or not to regain that elegance.
And, the whole idea of copy/paste having to use both mouse AND keyboard (select Ctrl-c click Ctrl-v) is barbaric. X11 got it right and it seems all "modern" apps are trying really hard to introduce barbarisms.
I think this is a reasonable set of objections to how cut and paste works if you were designing it from scratch. I'm not saying I agree with the conclusions, cut AND paste, is 2 operations so it seems silly to say you can undo both with 1 undo. It's kind of a RISC/CISC thing, is your opcode CUTANDPASTE or CUT and PASTE?
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.
I guess they've never heard of select-and-drag? Which isn't universal, but is common. And should be universal. I use it frequently. So many one-time-password forms break it in various ways, like wanting the value to go into six separate input boxes (why is this so common!?).
Ignoring whether this is a good idea:
- can this be made to work cross-application? You would have to be able to detect that a paste happened somewhere
- you can’t know whether a user wants to paste the same text twice. How do you handle that in the UI?
- how do you handle the case where, after copying, the user changes their mind, and never pastes the text?
It's an interesting thought, but hard to imagine how this would be implemented system wide. The clipboard would need to remember the source application, and have some kind of unique identifier to issue a delete to the source application.
This reminds me of File Explorer's cut behavior. It's a nice idea but the layout shift on paste is disorienting.
This looks so logical my mind struggles to understand why this is not how it already works in other programs o.O
the points on how undo interacts with this and the clipboard contents its also a good example of how relatively simple features can have a fairly high combined complexity to ensure the features do behave as expected if you use them in tandem.
nice writeup and cool solution :) thanks!
i see some comments about the move, and the cut & paste to be 3 actions etc. this is perhaps technically the case in current programs that you use, but conceptually and for most non-tech users this is not how the feature is presented. hence i think its a nice solution to fit the behavior to how its presented, rather than presenting more different ways to manipulate the document, using a move or other methods. (this would add complexity for non techy users. many editors which are mentioned are very complex with lots of keybindings)
It doesn't work this way because this breaks any use case that involves more than one program.
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
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.
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.
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.
Nothing.
So the "cut" file just disappears then? Is there an "undo?" That seems really horrifying.
No. The file disappearing is something. If you cut, and don't paste, nothing happens. And there is nothing to undo.
So the "cut" file doesn't disappear from its directory when you "cut" it? Only when it's pasted?
Seems complicated. Doesn't selecting, then drag-and-drop do what the author wants?
This is assuming you a) have a mouse, and b) want to use it. Some people are keyboard-oriented, and find the mouse too slow and/or inaccurate.
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)
Is there any kind of solution to saving everything that is cut or copied to some kind of temporary history so you can paste things you copied/cut like an hour ago?
That's called a clipboard manager and there are many of them.
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.
The first point should read "Cut is unundoable"
The mouse-driven EMACS I used in the 90s had a text swap feature that was so elegant - highlight one word, double-click another word, and boom - they swap places.
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.
>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.
Agree accidentally clobbering the clipboard is super annoying. Clipboard history apps are a godsend. Like Paste on Mac, or Windows has it built in.
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.
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.
Ya that’s too awkward. Clipboard history needs to be ⌘+Shift+V or I’d never use it
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
I haven't use Cut for ages. Not sure why, I guess because it is easy to move rather than cut/paste.
Oh if only cut and paste was broken... In Windows and Linux copy and paste itself is broken. Sometimes you copy with mouse, sometimes you copy with keyboard, and if it is a recent version of MS Office likely neither will work. Sometimes you paste with Ctrl+v sometimes with Ctrl+shift+v, sometimes with mouse, sometimes it just won't work. Such a simple operation should have been completely owned by the OS.
It works very reasonable on Linux/X11 with two separate clipboards - one for Ctrl+C/V and one for selection / middle click paste.
Ctrl+Shift+C/V is only necessary for terminals that already have other historical pre-GUI conventions for the Ctrl+ combinations - and you can always use a terminal emulator that lets you use Ctrl+C/V with the GUI semantics.
Interesting take on such a simple action but such a frustrating one when it does not work they way you want.
This is similar to how Explorer / Finder handle cut: The file isn't moved until paste.
In 30 years of using computers, never once have I used cut and paste.
How do you move or copy blocks of text, images, or lists of items?
why is this not an article abour the abomination of paste with formatting
Every implementation is the same, and no spec exists, so how is it broken?
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.
> 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.
Excel did this and it was pretty confusing.
this is one of those situations where I think the improvement is marginal over the value of standardisation.
> 2. Cut reflows 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. A tiny cognitive burden perhaps, but I'd argue an unnecessary one.
This is ridiculous. When I cut something in real life I expect it to be gone. Of course it reflows after that operation.
I don’t have a problem with this new operation but “redirect” is probably a better name, and not even a perfect one, compared to “Ghost Cut”
Cutting means removing, hence “being cut from the team”. This author is either having a hard time with English or being bombastic to try and sell their idea.
I just want a universal clipboard that works.
Cut & Paste always struck me as more of a Windows thing. Which is weird because obviously I can do cmd+X / cmd+V on a mac... I just never do. Instead it's "select" - command+C - delete - cmd+V.
Am I the only one who does that?
(EDIT: Same thing on Finder. cmd+C cmd+Del cmd+V)
Anyway, I love the design aesthetic of the site, and when people question existing paradigms. Will definitely be checking Ishmael out.
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.
[dead]
AFAIK, Chuck always used cut, undo, paste. I think he referred to copy & paste as being for script kiddies.
/s
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.
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...).
>every word processor, code editor, and browser text area you've ever used. yes that should have been the author saying "..I've ever used"