Rants on Emacs Visual Lines by Don Hopkins and Mark Crispin
by Don Hopkins,
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 Marc 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 Marc'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-asses 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.
Notes from Xah Lee
Don Hopkins is a oldbie, famously known as the guy who wrote The X-Windows Disaster (1994, as part of the 〈UNIX-Haters Handbook cover〉. 〔►see The Unix Pestilence〕 ). Don ported SimCities to X11 in the 1990s, and he's also oldbie Mathematica fan (as me).
Though, as you know, i couldn't agree with his rant on emacs. It is simply HABIT. As simple as that. Note his fortuitous likening of emac's changes to Microsoft Word.
Please Understand, that all the world's editors do visual lines, since about 1990s, including all linux ones (except vi 〔►see Emergency vi〕 ). But no, any change that displeases emacs oldbie will be said to emulate notepad to “dumb things down”. So, all the greatest software, created by Mac OS X X-code, and the vast majority of the world's most complex software are created by Microsoft Visual Studio, F#, used in financial industries, by NASA for space station, are the works of dumbed down programers using editor that emulates Microsoft Word. Imagine that. 〔►see Emacs Cult Problem: Emacs vs Windows Notepad〕
Also note, Mathematica has far more “smartness” than emacs or Microsoft Word. Tranparent automatic formatting of arbitrarily complex 2D math expressions as you type in real-time. It is strange, he doesn't bitch about that. But it is in the culture of emacs, to bitch about emacs changes.
WHO the f￼ck really created this visual-lines stuff in emacs? It is Stefan Monnier , one of the 2 current shot-caller of GNU emacs dev, and is a professor of functional language research. Thank you Stefan.
i have, of course, vigorously participated in the discussion. A bit harsh, no doubt:
I've written about 7 essays addressing this point in the past 10 years. See:
- Emacs Lisp: Automatic Code Formatting, Auto Indentation
- A Text Editor Feature: Extend Selection by Semantic Unit
- Programing: the Harm of Hard-wrapping Lines
- Programing: Tab vs Space in Source Code
- Unixer Plain-Text Email Fetish
- Unix, RFC, Line Truncation
- Emacs Why line-move-visual
- Emacs Form Feed (^L) Page Marker
Each of these is written in a different context, but they essentially discuss the same thing. That is, the importance of separating appearance/formatting from semantic or logical structure.
Here's a synapses on how each article relates to the line move visual issue.
• Programing: the Harm of Hard-wrapping Lines. A introduction. (a diatribe)
• Programing: Tab vs Space in Source Code. Introduces the idea as semantic based formatting vs hard-coded formatting.
• Plain-Text Email Fetish (Shows some connection of the hard-coded habit from unix.)
• Emacs Lisp: Automatic Code Formatting, Auto Indentation. A example of what actually can happen when hard-coded formatting hasn't become the conventional thought.
• A Text Editor Feature: Extend Selection by Semantic Unit. Another example of what could happen if unix didn't made people to think about hard-coded short lines.
• Programing Language: Fundamental Problems of Lisp. Half of the essay, discusses the above issues with respect to lisp the language, and consequences.