In this case, I'd yanked some text that I wanted to 'put' in a bunch of places. While going through the buffer, putting the text where I wanted it, I noticed a line that needed to come out, so I deleted it. Naturally, the next attempt to put gave me that line instead of the original text I'd yanked.
A side-effects undo wouldn't help you, though, would it, because in order to get your registers back, you'd have to undo past the change where you deleted the line, thus you wouldn't have accomplished what you needed to?
Yes, you are right (in fact, that's how I proceeded after realizing undo didn't restore the register stack). But I'm talking about ease-of-use and efficient editing, and 'p' is a lot faster and easier to type than '"0p'
That's true. What I tend to do is do a "0p and then immediately yy so I can then use just p for subsequent puts. Perhaps another possibility for you would be making a mapping, e.g. which does :let @"=@0 so that the last yank is again usable by just p. Just throwing in some ideas which might help you streamline your workflow without any additional features.
I also think that what I'm proposing presents a more sensible model of undo to the user.
Actually, I can't think of any other program that works this way, i.e. that undoes changes you make to the clipboard (whether the system clipboard, or some program-internal clipboard). I personally think undo should be about changes to documents, and that alone, and I think that is the consistent and sensible model adopted basically everywhere. In fact, I think it would be incredibly inconvenient if it wasn't. For instance, one thing I do often is 'go back in time' (whether using u, or using g-) to retrieve some text which I deleted (or which I added and later undid, so exists in a different branch of undo history), but which I now want to incorporate in my document once more. I then yank the text, step forward in time to my latest edit, and put it where I want it. If all my clipboard changes were undone and replayed, I wouldn't be able to do this. Old text would be lost forever, locked in the past, without resorting to tricks like writing it out to temporary files. Also, every time you yanked, you would create an undo point, but pushing undo would seemingly do nothing (except change registers behind the scenes). This is incredibly unintuitive. If taken to extremes, things like :set would create undo points too--this would be madness--no program undoes changes to its preferences with undo!
Ideally, (in my opinion), after 'undo', the world would be as if the undone command had never been executed. That's impossible to do perfectly, I understand that. But I think vim can come closer to the ideal than it does now.
Actually, now I think more thoroughly, even as much as you want isn't sensibly possible one you get past the simplest of simple cases. Registers are not document-specific, so, for example, if I delete some text in buffer A, then delete some text in buffer B, then undo the change to buffer A, what should happen? Should the registers revert to before I deleted from buffer A (without changing the text of buffer B, but also undoing the side effect of my delete from there)? I don't think there's any sensible way to resolve things like this--who knows what the user wants!--almost certainly the program couldn't always do what you want, and I doubt even if it behaved in some predictable way, any user could reliably keep track of what was going on in their head! I certainly couldn't! Grins, Ben. -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
