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.

/s

Personally, I have a hotkey set up just for pasting the second-to-last thing I cut or copied (Ctrl+Alt+V). This is handy for when I want to swap two things. Ctrl+Alt+(1 thru 0) will paste the last 1 thru 10 history entries.

>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 "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.

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.

Like yes, I get that in a strict engineering sense, that is the correct and least surprising behavior. But it's stupid and virtually guaranteed to not be what I wanted to happen. My expectation is what macOS does in this event -- nothing.

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.

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.

imagine having that guy as your roommate!

This is the fatal flow of the whole thing, with this it stops being a drop-in replacement.

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.

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.

which is exactly how it is supposed to work. why would I want previous state ? Why I'd even remember that state ?

> If you regret replacing your clipboard contents then too bad, they have gone poof in the digital ether.

Clipboard managers have been a thing since clipboards. Tho it would be nice to have one integrated, say so I can get menu of previous pastes with search and paste it in one step instead of "select what's in clipboard, then use it as normal" as it is with most

> 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.

Well unless you're pasting in exact same spot, how else would it work ? Editor doesn't even know if you want to paste it back into same document

> Undoing a paste will remove the newly added text, but it requires a second undo to completely restore the text—assuming there weren't any edits between the cut and paste.

that is because you might've pasted it in wrong space.

Sometimes the simple thing is better, because you can encode its way of working in your way of working without wondering 'oh why my pasted text was copied from'

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.

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.

issue here: https://github.com/anomalyco/opencode/issues/13984

ALWAYS default to regular behavior unless it's something you know exactly is going to go correctly.

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.

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.

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.

This is why copy and paste is broken for so many years, because devs at these beautiful companies, decided to let you wipe your end-user's clipboard when chatInputText.length === 0 or whatever. I noticed people having consistent issues with copy and paste when Teams became more prevalent, and it made no sense, until I realized.

If you work for one of these chat companies, for the love of GOD make an internal ticket, this is embarrassing.

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.