221–230 of 247 posts
1. visual undo/redo. I don’t want to be surprised when I perform either command. Show me.
2. visual clipboard with history. I don’t want to be surprised when I paste something. Show me. Also let me have more than one item in the clipboard.
Now I know some of you veterans will say, “there’s a plug-in for this! You just need to do these things…” no no no. I want this mainstream. Why are we living in the 1900s still?!
Earlier quoted context omitted.
And it is exactly why I find Emacs undo so hard to work with. But maybe I will get it now I've read this article.
Note that Emacs undo is not tree based, but works as described in the article. The tree based undo is a separate package one has to install.
I want two things before retirement: 1. visual undo/redo. I don’t want to be surprised when I perform either command. Show me. 2. visual clipboard with history. I don’t want to be surprised when I paste something. Show me. Also let me have more than one item in the clipboard. Now I know some of you veterans will say, “there’s a plug-in for this! You just need to do these things…” no no no. I want this mainstream. Why…
I'm having a hard time imagining an implementation of this feature that would be faster than "undo, check what happened, redo if undesired". I can see a need to explore the whole history (JetBrains IDEs have the local history), but what benefit do you see from previewing a single step?
> 2. visual clipboard with history. I don’t want to be surprised when I paste something. Show me. Also let me have more than one item in the clipboard.
CopyQ is a great tool that does just this, available on Linux and Windows. I'm sure there's an equivalent for Mac.
EDIT: also, not to plug JetBrains again, but their IDEs have clipboard history built in within the editor. I have CopyQ for system-wide clipboard history, so I don't bother with it, but it's there.
Earlier quoted context omitted.
Wait until you say this after 10 years.
After 10 years he might even be as fast as with a non-modal editor.
Because yeah, vim won't beat IntelliJ, but you can get it to be pretty decent with LSP:
Earlier quoted context omitted.
And it is exactly why I find Emacs undo so hard to work with. But maybe I will get it now I've read this article.
See `:h undo-persistance` for that feature. In particular you want to do `set undofile` in your vim config
I want two things before retirement: 1. visual undo/redo. I don’t want to be surprised when I perform either command. Show me. 2. visual clipboard with history. I don’t want to be surprised when I paste something. Show me. Also let me have more than one item in the clipboard. Now I know some of you veterans will say, “there’s a plug-in for this! You just need to do these things…” no no no. I want this mainstream. Why…
> 1. visual undo/redo. I don’t want to be surprised when I perform either command. Show me. I'm having a hard time imagining an implementation of this feature that would be faster than "undo, check what happened, redo if undesired". I can see a need to explore the whole history (JetBrains IDEs have the local history), but what benefit do you see from previewing a single step? > 2. visual clipboard with history. I don…
Cool! What about a model based completely on the "history" as a list of states of the document over time? There is no "undo" or "redo" operation, we only have "browse backward/forward in time". If you are browsing at a point in the past history, you can just start editing. Then the document state is copied to the end of the history (i.e. the current point in time), followed by your edits, etc. This removes the 2^n pr…
That is basically the same as the proposed skipping of B in navigation. It does however require the ability to put "make document look like X" (where X is the old state) as a single undo stack entry. If your app design allows that, great, squashing all of B into a single entry would work fine. Such an implementation would be: if you go back and try to make a change, it moves everything from the redo stack to the undo…
many editors collapse edits into a groups and you can only undo by groups, not individual keypresses. This is usually desirable. For example type X then cursor right 60 times then type Y then undo 3 times. Are you at 2 characters before where the Y was or back at the X or before the X? In other words, were the 60 cursor right keypresses collapsed into 1, 2 steps or not collapsed at all
Good editors spend some time thinking about the most expected group definitions, bad editors (vscode in this specific case) seem to have picked a random number for their group size or a even a fixed number of keypresses but it feels random. There's no predicting how much it's going to undo in a single Ctrl/Cmd-z. Ii rarely does what I want compared to other editors
Two important things to point out about this approach:
1. you will never lose any previous information (barring memory limitations). You can be confident any previous state can be retrieved somewhere along the linearized history, and you don't need to search along a potentially thousand branched tree. Just follow the linear history and you will find it.
2. this tracks the chronological state of the buffer. For some reason, people do seem to get confused with Emacs's undo functionality because they're familiar with the "Microsoft Word" style undo, but I feel like it's intuitive if you think of it as a literal timeline of the buffer state. If you want the state of the buffer five minutes ago, you will need to undo past the one minute ago state, the two minutes ago state, etc. And then two minutes later, you can undo two minutes back to get the same state again even though the "original" state is now seven minutes ago, because when you "undid" you brought the buffer back to that state in the present.
Earlier quoted context omitted.
What a great feature! Is the author of that feature here? If so, I want to know how they could develop such a feature and be so quiet about it. It's like someone baking a birthday cake and then dropping it down an abandoned well. Just imagine how much more productive we'd all be if Vim bros were as loud as the crypto bros over the past decade!
You just need to get vim bros going. Just go "omg I hate vi so much" at a tech meetup and sit back for the fire hose of vim features to start.