Hacker News new | ask | show | jobs
by bambax 5 days ago
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".

2 comments

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

> 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

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.
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).
Why stop there, move back the clock as well. And send requests to all the remote hosts to send our packets back.
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