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.
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
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.
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.
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.
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.
> 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.
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.
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!
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.
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.
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.
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.
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.
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.
> 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 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.
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.
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.
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.
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
> 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.
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.
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.
90 comments
[ 0.36 ms ] story [ 29.8 ms ] threadI know that’s obviously not the case, but Excel is just so unintuitive in so many ways (for me).
* 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.
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.
> doing the expected thing for most people most of the time
citation needed.
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.
>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.
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.
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.
TFA and comments are clearly a solution is search of the problem.
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.
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!
I first encountered clipboard history in Jetbrains Rubymine editor
imagine having that guy as your roommate!
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.
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.
Why would you cut + undo as opposed to just copy? Are they not the same operation at that point?
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).
That's basically drag & drop (on macOS).
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".
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.
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
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.
/s
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.
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.
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.
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.