Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ghost Cut – Or why Cut and Paste is broken everywhere

ishmael.textualize.io

Post reply on HN
Print view View original

41–50 of 162 posts

Re: Ghost Cut – Or why Cut and Paste is broken everywhere

#41

Post by croes »

Mogzol wrote: post #32
throwawayffffas wrote: post #22

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 c…

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

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

Cut + undo, is copy with visual feedback

Re: Ghost Cut – Or why Cut and Paste is broken everywhere

#42

Post by rpdillon »

rickydroll wrote: post #35

Cut and paste is a UI failure; it only works kinda if you have fully functional hands. If your hands don't work right, or you have tremors or other mobility impairments, your chances of succeeding with cut and paste drop off significantly. 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…

Reading through the post, it was clear that the author wasn't very familiar with Emacs. I'm a huge fan of the undo model of Emacs, especially with tools like undo-tree (although cycling through with M-y is basically as good for my use cases). The "replace the clipboard" bug doesn't exist because Emacs has a killring (I'm such a fan I bought killring.org years ago!), and the "text reflows" problem is completely solved use C-u C-space to traverse the mark-ring. His final point, that it is multiple operations, I simply disagree is a bug...multiple operations is fine, because I can compose them in a way that suits my workflow. Of course, in Emacs it would be trivial to write Ghost Cut (though it would only work within Emacs...).

Re: Ghost Cut – Or why Cut and Paste is broken everywhere

#43

Post by Wowfunhappy »

justsomehnguy wrote: post #38
Wowfunhappy wrote: post #8

> 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), b…

Even if it was 2GB of some data? Even if you run low on memory? TFA and comments are clearly a solution is search of the problem.

Is it possible to copy 2GB of data to the clipboard? If it's an image or something I'd expect the clipboard to contain a reference to the image or some such. How do clipboard managers handle this?

Re: Ghost Cut – Or why Cut and Paste is broken everywhere

#45

Post by [deleted] »

jubilanti wrote: post #39
sharkjacobs wrote: post #36

Earlier quoted context omitted.

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.

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

[deleted]

Re: Ghost Cut – Or why Cut and Paste is broken everywhere

#46

Post by layer8 »

> anything more than you are doing already. 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.

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.

Re: Ghost Cut – Or why Cut and Paste is broken everywhere

#47

Post by Cockbrand »

cush wrote: post #17

Agree accidentally clobbering the clipboard is super annoying. Clipboard history apps are a godsend. Like Paste on Mac, or Windows has it built in.

The Mac now has a clipboard history as well, it's just a bit awkward. You can open Spotlight with ⌘Space, and within Spotlight open the clipboard manager with ⌘4.

Re: Ghost Cut – Or why Cut and Paste is broken everywhere

#48

Post by drdexebtjl »

Wowfunhappy wrote: post #30
drdexebtjl wrote: post #25

Earlier quoted context omitted.

The problem with Undo reverting the clipboard state is that Undo is usually file or app-local, but the clipboard is shared. You can cut from app A, switch to app B, cut something else from app B, then go back to app A and undo the cut. “Ghost cut” can work across apps with reasonable undo support by not using the clipboard at all and some form of IPC instead. For example, when you cut from app B before resolving the…

> You can cut from app A, switch to app B, cut something else from app B, then go back to app A and undo the cut. ...right, thanks. So you could still make it work but you'd definitely need OS support, it's not something one app can fix. Edit: You could make this work on an app level by checking if the contents of the user's clipboard is still the value they cut. If yes, revert to whatever clipboard contents you save…

What would be in the clipboard after the undo in that scenario?

edit: Yeah, the problem is that the user does not expect undo to do something different depending on what they did on a different program.

Undo doing nothing to the clipboard always is more consistent and the better UX.

Re: Ghost Cut – Or why Cut and Paste is broken everywhere

#50

Post by panic »

kps wrote: post #11

Star didn't have cut/copy/paste. Instead it had ‘copy to’ and ‘move to’ operations on the current selection, more like today's drag-and-drop. Some influential people decided that invisible fragile clipboard state was better than a copy/move-in-progress state.

A 2012 historical retrospective on the subject from Larry Tesler (the NOMODES man himself): https://www.lri.fr/~mbl/ENS/FundHCI/2013/papers/Tesler-CutCo...

The issue he had with the “move to” operation is that it forced you into a mode where you had to pick a destination right away. I wonder if OP’s proposal was ever brought up at the time—it does seem like a promising middle ground!

Post reply on HN