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

[rao-v]

It’s not unreasonable to suggest that text editors need a nice atomic move (but personally I don’t see the need for it)

[brianush1]

in most editors you can just select text and drag it around with the mouse

[bambax]

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

[throwawayffffas]

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

[eviks]

> 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

[bambax]

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.

[eviks]

Maybe internal registers are the primary way, though that prevents some niche cases like clipboard watchers (copied #hex color to clipboard, have an option to insert any other format).

[throwawayffffas]

Why stop there, move back the clock as well. And send requests to all the remote hosts to send our packets back.

[eviks]

One reason to stop there is because your examples are absurd, while mine aren't. The are already apps where you have undo stacks for selection and text cursor positioning, so coupling that with the "state of the world" is an option. But unfortunately absurdity doesn't offer any guidance just like shallow absolutes. Think harder

[the_lucifer]

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

[toast0]

I dunno, in my preferred text editor (joe), i set up a selection, and I can delete it if I want, or go where I want it and do copy or move the selected region.

[FabHK]

> you could have a separate short cut that grays out the text and then moves it to where you want.

That's basically drag & drop (on macOS).

[windward]

>paste multiple times

Because you're trying to 'copy' it?

This feels baby-duck-y. No given mental model is more right than another. There's already not even a consistent model, because:

>Cut is copy and delete

So copy and delete! Or, in Vim and Emacs, just delete!

[arijun]

> Or, in Vim and Emacs, just delete!

Off topic, but that’s actually my biggest pet peeve vim. You copy text one place to overwrite some other text, you delete the existing text and they you go to paste and… the buffer has been overwritten. It makes so much more sense to require users to hit the obvious, composable ‘yd’ in the cases they want to copy than an arcane incantation in the cases they want to overwrite text.

[windward]

Spending enough time drinking the kool aid means I know at least 3 ways to use registers to avoid that, and practically end up using none of them

[allarm]

_d

D

_dd

[Mogzol]

> I cut, undo, ..., undo, and paste multiple times a day.

Why would you cut + undo as opposed to just copy? Are they not the same operation at that point?

[sharkjacobs]

I often cut + undo because seeing the cut is feedback which tells me the operation successfully put the content into clipboard. This is not always a guarantee especially in web apps, and sometimes I just have focus on the wrong window.

[mjmsmith]

How can you be sure that the undo stack is in sync with the clipboard? Wouldn't cut+paste be a more reliable pseudo-copy than cut+undo?

[TeMPOraL]

> How can you be sure that the undo stack is in sync with the clipboard?

Simple: they're not meant to be. Undo stack and clipboard are orthogonal. It's like foundational rule of computing.

[jubilanti]

Have you used a clipboard manager? There are tons that you can configure with notifications and indicators, so you don't have to that.

[nkrisc]

Having to install yet more software seems worse than the problem you’re suggesting it should solve.

[michaelmrose]

Even windows has this software out of the box because it is so obviously useful

[ashdksnndck]

At least it would save you a keystroke every time, if it enables you to switch from cut+undo to copy.

[vjulian]

I feel as though I’m reading the script to a Monty Python sketch.

[croes]

Have you never copied, tried to paste and you pasted the wrong thing because copy failed?

Cut + undo, is copy with visual feedback

[efreak]

Copy and paste gives you visual feedback without reflowing the document. I also use it to intentionally add a marker in undo history in documents in not planning to change, as that way I can use the undo history to jump to different areas.

[croes]

Where does Copy give you feedback that you actually copied something?

[efreak]

The paste action gives you feedback by having the cursor move to the end of the selected text after it replaces the text you copied with itself.

If you're on Android, lately it actually does give feedback by putting the copied text into the predictive text/autocomplete bar above the keyboard (I find this annoying as I'm usually copying text to save for later use, and I use the appearance of text I want in the corrections as an indication I've swiped wrong. If only I could touch-type while lying down...). In other apps that don't display the keyboard, it sometimes gives you a toast that an app has access the clipboard, though it gives the same toast for pasting or just for accessing it (eg pasting with termux or using an RDP app that syncs the clipboard)

[croes]

That’s too late, if copy didn’t work or I copied the wrong part I have to go all the way back and select the part to copy again.

That’s why Ctrl-X, Ctrl-Z is the way

[eth0up]

In Linux, if under XFCE, strangely by default, Clipman keeps a log of all text ever copied, in a giant textsrc file ( .cache/xfce4/clipman/textsrc )

That is kind of the opposite though, and more of a passive, almost furtive, indelible clipboard feedback. I was pretty astonished to find it, hovering somewhere near 4MB with years of content.