Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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.by trgn
- 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.by ericyd
- Well, it's useful. When the iPhone initially didn't support it, people were unhappy, and it was added soon enough.by FabHK
- 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.
by atq2119 - 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.
by reichstein - > 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.
by FabHK - 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.
by jerf - 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.by dec0dedab0de
- "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...
by xg15 - 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.
- 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.
by wodenokoto - 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.by tectec
- Half of the time it doesn't work as well.by varispeed
- 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.
by Noumenon72 - 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.
by FabHK - 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).
by AndroTux - 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.
by nlawalker - 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.
by abanana - 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
by gbalduzzi - 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.
by Diogenesian - 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.by kmoser
- 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.
- 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.
- > 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?
by Mogzol - >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!
by windward - > 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).
by FabHK - > 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).
by the_lucifer - 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".
by bambax - It’s not unreasonable to suggest that text editors need a nice atomic move (but personally I don’t see the need for it)by rao-v