Interesting commentary. I do think this is a little harsh on the poor Emacs undo system.
I can't really push back on the idea that Emacs' undo system is excessively confusing, because I use Emacs and I don't understand it. I usually save text in a second buffer if I think I'll need it later.
But the solution should be to improve the UI rather than remove functionality. Consider what magit did to a similar problem in git - git is powerful with a weirdly crippled CLI. Magit adds a great ... Emacs User Interface? EUI? and all is well.
There is a probably a similar solution to the Emacs Undo problem.
Absolutely not. In typical Emacs fashion they took a serious complaint, fixed it and then went on to overdo it, making it unusable overkill and slow. One step redo would have been enough.
nope. what i mean is doing undo operations on a project as opposed to a buffer. lets say you have 3 buffers open and you edit buffer 1 (i), then you edit buffer 3 (ii), then you edit buffer 2 (iii), and then back to buffer 3 and you edit it some more (iv). finally you want to do project-undo from this point in buffer 3. the undo sequence then goes like this:
Doesn't the kill ring also behave similarly. That if you move through the kill ring and stop, next time it will start from that point, rather than the latest killed text?
I think the default M-y does that and it's confusing. helm-show-kill-ring or counsel-yank-pop makes this much more manageable kind of like how undo-tree makes undoing simpler.
I can't really push back on the idea that Emacs' undo system is excessively confusing, because I use Emacs and I don't understand it. I usually save text in a second buffer if I think I'll need it later.
But the solution should be to improve the UI rather than remove functionality. Consider what magit did to a similar problem in git - git is powerful with a weirdly crippled CLI. Magit adds a great ... Emacs User Interface? EUI? and all is well.
There is a probably a similar solution to the Emacs Undo problem.