Ghost Cut: Why Traditional Cut and Paste is Broken Everywhere
Ghost Cut – or why Cut and Paste is broken everywhere
I argue that the standard cut and paste workflow is fundamentally flawed because it is not atomic, causes unnecessary document reflow, and fails to fully undo clipboard changes. To solve this, I introduced Ghost Cut in Ishmael, a mechanism where cutting fades text without moving it to the clipboard until you paste. This approach allows for a single-step undo and eliminates the cognitive burden of re-locating text, offering a cleaner, more reversible editing experience.
Cut and paste is the combination of two operations, yet it is broken in every word processor, code editor, and browser text area you have ever used.
- throwawayffffas
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.
- Diogenesian
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.
- wodenokoto
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.
- voidUpdate
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?
- nlawalker
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.
- abanana
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.
- tectec
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.
- Someone
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?