Speaking of cut in File Explorer, Will McGugan, creator of the writing editor Ishmael, proposes doing the same thing for text editing – that is, leaving ghost text behind:

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.

I do not think this is a good idea. It seems like McGugan proposes somewhat arbitrary reasons that cut and paste are “broken,” and to me the proposal fails even within his own framework: for example, it still doesn’t avoid the reflow, but moves it to the other side, making paste feel unstable (the included JavaScript playground feels disorienting to use). I think it also is at odds with the editor’s own about page, which talks about distraction and simplicity – and yet, what’s introduced here is a host of complex new things: a new visual state for cut text (that looks like AI autocomplete), some new logic to avoid moving into the cut text (which will also prevent easy selection adjustments), likely new confusion around undo, and a necessary new Esc gesture to get rid of a cut you decided not to pursue.

But! There is something interesting in seeing this ghost text, and specific critique aside, it is fun to see experiments like these, with interactive explainers, poking at long-established interactions. Just yesterday, a second one appeared: an interesting new way to extend selection upwards – similar to double and triple clicking on text, but via the keyboard. This is the power of prototyping: sometimes seeing an idea you disagree with is the only thing that can unlock a different solution in your head.

Let’s go back to cut and paste, though. You will notice that what’s listed as a precedent is not File Explorer, but Excel. It also doesn’t immediately remove selected cells on cut, but leave them in a temporary “possibly getting moved or removed” state first, only to have them disappear after paste:

Why is that? I believe out of a similar principle, but a distinct reason that File Explorer too opts to leave a cut ghost behind. The stakes are higher in a different sense: cells refer to other cells. Were the removed cells to disappear immediately, you might witness the rest of the spreadsheet error out or show zeroes, as its formulas start pointing to emptiness.

And it’s a good principle to generally avoid frightening your users.

Here’s an example from Numbers, which doesn’t do ghosting, making cut a bad choice to do a simple move, as it doesn’t even recover after paste: