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.
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 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.
> 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.
This reminds me of File Explorer's cut behavior. It's a nice idea but the layout shift on paste is disorienting.
Seems complicated. Doesn't selecting, then drag-and-drop do what the author wants?