Here's an old rant from 2013 that Xah Lee archived and replied to, but that he didn't agree with, but that the late Mark Crispin covered in his own rant in 2011:
(TLDR: Don't try to change emacs into Microsoft Word without understanding why it is the way it is, don't change long-standing essential defaults out from under people, and don't break type-ahead and keyboard macros.)
https://wilkesley.org/~ian/xah/misc/Don_Hopkins_Mark_Crispin...
[Don wrote:]
>The wrong people have been drunkenly driving Emacs into the ditch for the past decade or so, and they're really screwed it up in so many ways, usually trying to be way too clever and solve problems that really aren't worth solving.
>They made “line-move-visual” the default, which in the service of making Emacs behave more like Microsoft Word, it makes ^N and ^P across wrapped lines stay on the same line and move to the part of the same line that is wrapped above or below the cursor, totally breaking type-ahead predictability and keyboard macros. That totally pissed of the late and long time Emacs user Mark Crispin, and he explains why it's such a terrible idea that breaks keyboard macros: http://compgroups.net/comp.emacs/line-move-visual/274792
>It totally breaks keyboard macros, one of the most important things about Emacs. It definitely should not have been made the default, since keyboard macros are a way of life for real emacs hackers. I totally agree with Mark's take on the problem, and I am terribly disappointed that RMS let somebody get away with changing it that way, and making that horrible mode the default.
>They just can't stop trying to make it more like Microsoft Word, while failing to actually achieve that goal, and only succeeding in inflicting half-assed solutions with harmful unpredictable side-effects on the users.
>Another example is how the region highlighting and the weird pending delete behavior terrorizes me that sometimes but not all the time according to rules I just can't figure out or tell by looking at the screen, when I type something that I intend to insert, a huge chunk of my buffer might just disappear, but sometimes it doesn't. So now Emacs has become unpredictable and malicious. I have to do a dance of “insert character, undo” to know that I have canceled the pending delete mode. You can't tell if you are in pending delete mode just by looking at the screen and seeing the obnoxious highlighting, because sometimes it highlights the region and isn't in pending delete mode, and sometimes it highlights the region and is in pending delete mode. I just wish it would stop highlighting the region, because any time I set a mark and move around, it highlights half of the screen at no use to me, and that just gives me a headache, and I have to insert a character an undo it to cancel the highlighting, and until I cancel the highlighting I am living in terror that my next keystroke will delete a huge unseen portion of the buffer.
>And the thing that REALLY pisses me off is the lame-assed attempt to make ^A and ^E ignore the prompt in shell mode. There is an extremely simple reliable solution to the problem of separating the prompt from your input in shell mode so you can always get to the beginning of the line with ^A, and that is to have a newline at the end of your prompt, so every line you type in is on the whole line and does not have a prompt prefix, therefore no half-assed magic is necessary.
>But the half-assed magic is terribly implemented and has bizarre side-effects that screw me all the time: I get these fucking invisible force fields inserted into the line between my characters whenever I yank some text onto the line that has a prompt or a command line on it, and I can't move past them with ^A or ^E (but sometimes I can — they're not predictable which is even worse)! And I can get any number of these fucking invisible force fields on my line, so in order to get to the beginning of the line I have to go ^A, look at the screen to see if I made it, type ^B ^A if I didn't, again and again, until I drill past all the invisible force fields that are trying to make my day happier.
>And then I have to mark the beginning of the line I want to edit and repeat, go to the end of line by drilling back some number of opposite facing invisible force fields (which may be in different places than the ones going the other direction), and then kill the region, go to the end of the buffer, then yank the entire line to get a copy of it without any fucking invisible force fields in it.
>But if there is an invisible force field in the line, or I just want to edit a few characters of the line and that adds some invisible force fields that were not even there before, and then I hit return in the vain hope of re-entering the entire line but not the prompt, it just enters the tail of the line after the last invisible force field, making an error in the shell, or sometimes even executing a totally different command than I intended and totally fucking me over.
>I would really like somebody to explain what the fuck the idea behind the invisible force fields are, and give me the address of whoever thought is was such a brilliant idea, so I can send a robot drone to firebomb their house, or worse yet send RMS to live with them for a few months. Why did they do something so terrible, that totally fucks up such common important operations, to solve a trivial problem that has a much better solution?
>Emacs used to be totally predictable. I learned it at 300 baud over the ARPANET on ITS, and I could type ahead hundreds of characters to do all kinds of stuff, and then go take a piss or get a drink or take a bong hit, and come back later, and it would be in exactly the state I meant for it to end up in. Now, I can't do that even on a local display. And for some fucking reason, it waits for up to five seconds sometime before updating the display when I'm running it in a terminal (especially when I start an incremental search or query replace). What the fuck is that about??! Not only is it totally unpredictable and forces me to stop what I'm doing and wait for it to catch up so I can figure out what state it guessed its way into before going on, but it won't paint the screen for five seconds when running on a modern top-of-the-line computer!
>Emacs has become a shrine to outrageous violations of the principle of least astonishment. I just can't figure out how they could have come up with so many ways to corrupt it, when it used to work so well. It's totally unpredictable now, and I can't type ahead any more, so I have to type a few characters, look at the screen to see how it misinterpreted my intentions, and then try to work around the misunderstanding.
https://wilkesley.org/~ian/xah/misc/Mark_Crispin_emacs_line_...
[Mark wrote:]
>emacs line wrap rant by Mark Crispin 2011-06-03
https://groups.google.com/d/msg/comp.emacs/Q1SeBV1kkIs/vmY_e...
>What mindless cretin thought that it should be a good idea to make line-move-visual be the default in emacs 23?
>I just found out about this charming "improvement" in the worst possible way. Investigation determined that a "routine" software update had just installed emacs 23 and gave me this "improvement".
>People wonder why everybody hasn't dumped proprietary desktop software. This is an example why. Emacs' line behavior has well over 30 years of history, and some bagbiter goes and changes it BY DEFAULT.
>Add all the cute new features you want. But leave the goddamn defaults alone.
>If you want to have your own playpen where you twiddle defaults to your hearts content, have at it. But don't pretend that you produce software for a production environment, and stop telling the Linux distributions that they should "upgrade" to your "improved" versions. People doing real work depend upon those distributions.
>It does no good to say "read the release notes" when the affected users don't get the release notes and don't even know that a new release happened. It is also unreasonable to expect users to subscribe to every obscure newsgroup, forum, and wiki to hear about changes that will turn their expectations upside down.
>Yes, I fixed my .emacs file. And I'm putting in the same change to all the .emacs files on all the dozens of other machines I use, even though they still have emacs 22, because otherwise this unpleasant surprise will repeat itself over and over again.
>Grr.
>>On Thu, 3 Jun 2010, Uday S Reddy posted:
>>I am not taking sides on the line-move-visual issue. But I do know that it was a complex decision for the Emacs developers and it wasn't made easily.
>They made the wrong decision. Changes to default behavior are a bad idea. Changes to default behavior of the most basic functionality are an extremely bad idea.
>I don't care if M-X fart-noisily-with-spray changes its default scent from skunk to lemon. But I damn well do care about the most basic operations: all CTRL single letter and ESC single letter. After 33+ years of using emacs, I expect these to be reliable and not suddenly change.
>I wasted hours trying to figure out what the hell was wrong with my file, or my terminal emulator window, or my system. The fact that the problem went away on a different system added further confusion. It was only when I did ESC <n> CTRL/N and saw that it moved me the wrong number of lines, but only on one system, that I realized that emacs changed. And that's when I did ESC X describe-key CTRL/N and read about line-mode-visual, although it did not mention that this was now the default.
>Surprise. Grr.
>>However, I am concerned about downstream distributions that omit the release notes. That seems to be a real disservice to the users.
>So I find a system with the release notes. And the reference to this incompatible change is buried 300+ lines deep, after numerous pointless entries such as emacs having a character set 4 times bigger than Unicode.
>-- Mark --
>>On Fri, 4 Jun 2010, Tassilo Horn posted:
>> But all visual line behavior break keyboard macros. Define a macro, then change your window size (so that lines are differently visually wrapped), and bang your macro messes up your text. It's semantics change with the frame/window size. That's silly.
>This is precisely how I got screwed by this incompatible change. But the change in behavior also confused the hell out of me. Almost all of my editing is C source code.
>>Because keyboard macros are important to me, I set line-move-visual to nil.
>Yes.
>-- Mark --
[Don writes:]
To be fair, Xah has written his own pro-line-move-visual rant:
https://wilkesley.org/~ian/xah/emacs/emacs_line_move_visual....
I respect Xah's position, and he wrote a lot interesting text and links and emacs history and learned opinion, but I won't quote it here, because I still disagree with him, and he doesn't address the fact that line-move-visual BREAKS keyboard macros, and keyboard macros are one of the most important reasons and powerful techniques for using Emacs.
But I quoted Mark's rant because I agree with him, he wrote MM and IMAP, his TELNET UI design inspired GLS to write the Telnet Song, and he had the panache to use terms like "cretin" and "bagbiter" and "M-X fart-noisily-with-spray". ;) RIP Mark Crispin.
https://en.wikipedia.org/wiki/Mark_Crispin
Title: Telnet Song, Poet: Guy L. Steele, Jr
https://web.archive.org/web/20040111114819/http://www.cs.ric...