Goddamn m�th�rf�cking emacs undo.
Emacs undo is a m�th�rf�cking problem. There's a “redo” mode, which i've been using since about 2006. However, that mode sometimes corrupt your undo. That is, you tried to undo, but it says no more undo.
Sometimes in 2010 i discovered a improved redo mode, called “redo+”. I was happy, and put it in ErgoEmacs replacing the redo mode. However, now having used it for several months, i discovered that it's got a worse problem, a major one. Sometimes in a text file “.txt” (text-mode), it simply doesn't let you undo at all. It says “undo-more: No further undo information” — My ass! (at that point, you have to call “revert-buffer”.)
F�ck emacs f�ckfaces. Those so-called “leet”, “hacker”, scumbags.
What's emacs undo problem? Emacswiki said the best (see: http://www.emacswiki.org/emacs/RedoMode), quote:
Emacs treats “undo” as just another command. Therefore you can undo the undo. This is powerful and confusing, because if you are doing several undos and miss the “correct spot”, and do anything at all which is not an undo command, you will be stuck: You broke the chain of undos. When you realize your mistake and try to undo some more, you will first undo your previous undos, then undo the dos, and then you can finally undo some more to find the correct spot. The problem is at least as confusing as this description.
Fundamental problems like this cannot be fixed by 3rd-party packages. It needs to be fixed in emacs core. Similar issues are copy/cut keys conflicting with emacs's 【Ctrl+c】 and 【Ctrl+x】 beginning key shortcut combination, and down arrow key for moving down a visual line (fixed since emacs 23 〔➤see Emacs 23.1 New Features (released 2009-07)〕).
Issues that are likely to become a cult problem are those unique in emacs. (Another is the “*scratch*” buffer.) These problems, on the surface are technical design issues, but have become identity crisis issues. (because, if it is changed, to the lurid-news sucking populace it seems to indicate admittance of bad design and defeat . (which is not true, because tech do need to evolve. (Apple had the same problem in some areas, ➢ for example: 1-button mouse, menu bar at top of screen, window cannot be resized by any edge.)))
Whenever these problems are raised, and they are raised frequently on blogs and programing sites such as hackernews, reddit, by common programers, a bunch of emacs diehards will insist that emacs way is the superior way. (and quickly the thread will degenerate into “emacs vs vi” inane cult f�ck) The problem is not due to lack of due diligence or intelligence, but stem from a cult problem. As long as the emacs cult isn't killed, it will continue to harm emacs. Typically, emacs will adopt the superior but non-emacs-originated design after 5 to 10 years after the industry. (➢ for example: mouse and GUI support, syntax highlighting, arrow-down to move by visual line, all happened after 5 to 10 years)
What to do if you love emacs and want emacs to improve? Persistent in spreading what is true. Fight the emacs cult. Remember: PERSIST. Each person may have different styles and time to devote on this. You may, like me, simply tell the emacs cultists to f�ck off and eat shit and die. Or, perhaps you are like most people, who are not so radical in manners, and participate in debates in mild and reasonable manners. But remember one thing: PERSIST.
To simply insist my point of view, is NOT ME. But it is my belief that many emacs issue are by all scientific judgments without doubt to be the opposite of the leet view held by traditional emacs diehard users, to the point that to still participate in a mild reasonable debate is in fact bordering on cowardice and lie.
The problem does not seem to be “redo+” mode, but a esoteric bug. Steps to reproduce:
(define-key key-translation-map (kbd "M--") (kbd "─"))(it lets you press 【Alt+-】 to insert a Unicode char “BOX DRAWINGS LIGHT HORIZONTAL” (U+2500).)
Notes: The exactly Unicode char doesn't matter. The key used doesn't seem to matter neither. Perhaps even Unicode doesn't matter. The problem seems to be using “key-translation-map” and with universal argument.
the various undo/redo packages often cause undo to not work. Either as a bug, or, something else went wrong in emacs that indirectly caused these packages to unable to undo.
Note: i have long found that redo can often corrupt the buffer and your only recourse is to kill the buffer, or diff with backups. it would be great if there were a redo without this bug. maybe undo-browse.el? --gambarimasu who is at gmail
undo-tree package problem:
i had reverse situation. I stopped using unto-tree last month, after a decade of packages with undo+redo. (before that, it's 6 years plain emacs in terminal)
the minor reason that made me stop using undo package is that, when writing modes output to buffers, for some reason, once or twice the undo-tree doesn't work, either that or i need to do something in my code, or something else. This is very annoying. Because when you tried to undo, but found out there's no undo record at all because something went wrong, you lost potentially important info because i expected undo to be there.
over the decade i was using various packages of undo/redo, they all have this problem. Worst is when it corrupts the undo record.
It needs to be part of core gnu emacs.
Because when you tried to undo, but found out there's no undo record at all because something went wrong
This happens to me all the time, especially after pasting. I've also encountered a problem where the undo tree file somehow becomes corrupted (happened a lot for the same files), causing emacs to crash every time the corresponding file is opened. Annoyingly, it was happening for my org files that I would use to take notes while listening to people speak in real time. Deleting the corrupted file prevented the crashes, but it happened so often, I had to turn undo-tree off when taking notes. I love undo-tree, but it has some really frustrating bugs.
by angelic_sedition, , at https://www.reddit.com/r/emacs/comments/3yt467/emacs_new_years_resolution_use_undotree/