3 ms·
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
by throwawayffffas 3mo ago
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.
- windward 3mo ago>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 3mo ago> 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.
- Mogzol 3mo ago> 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 3mo agoI 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.
- jubilanti 3mo agoHave you used a clipboard manager? There are tons that you can configure with notifications and indicators, so you don't have to that.
- deleted 3mo ago[deleted]
- nkrisc 3mo agoHaving to install yet more software seems worse than the problem you’re suggesting it should solve.
- michaelmrose 3mo agoEven windows has this software out of the box because it is so obviously useful
- ashdksnndck 3mo agoAt least it would save you a keystroke every time, if it enables you to switch from cut+undo to copy.
- mjmsmith 3mo agoHow 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?
- the_lucifer 3mo ago> 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 3mo agoI 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.
- rao-v 3mo agoIt’s not unreasonable to suggest that text editors need a nice atomic move (but personally I don’t see the need for it)
- brianush1 3mo agoin most editors you can just select text and drag it around with the mouse
- FabHK 3mo ago> 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).
- bambax 3mo agoI 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 3mo ago> 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 3mo ago> 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
- throwawayffffas 3mo agoWhy stop there, move back the clock as well. And send requests to all the remote hosts to send our packets back.