Emacs Why line-move-visual
This page discuss a new feature in emacs 23.1, that pressing the down arrow key moves cursor to the next line as seen on the screen, not by EOL (end of line character), controlled by the variable line-move-visual.
[ Mark Crispin ] [ https://en.wikipedia.org/wiki/Mark_Crispin ], inventor of the email IMAP protocol, one of the earliest user of emacs (before Richard Stallman), posted a message on newsgroup comp.emacs, aggressively attacking a emacs 23.1 change about how the key C-n or arrow keys move the cursor across lines. The thread now has over 110 messages. The original thread is here comp.emacs, some later messages are posted to gnu.emacs.help.
In his opinion, emacs should not have changed this fundamental behavior. Here are some of my responses in the thread, summarizing why i think it is a good change.
Problem of longline-mode
[note: longline-mode is a minor mode in emacs 22.x. It makes long line soft-wrapped on a right margin (not just at the edge of window), and also when you press arrow down, it moves cursor to the next line as defined by the screen display, not by EOL.]
Brendan Halpin wrote:
Attempted thread-jack: why use visual-line-mode instead of longlines-mode?
[note: visual-line-mode is a new minor mode in emacs 23. It turns on line-move-visual and other things, basically does what longline-mode do. For detail, see: Emacs 23.1 Features (released 2009-07).]
longlines-mode has serious bugs, i believe still so even i haven't used it since emacs 23.1 came out a year or 2 ago.
Basically, whenever large chunk of text is inserted or removed in a buffer (either manually, or sometimes automatically by commands such as patch and version control etc), then the text will be screwed up… missing parts or something like that.
I filed a bug report about it, and subsequently discovered that there were already bug reports of it in emacs bug track. If i recall correctly, the situation is that it's hard to fix, because longlines-mode was a hack for lack of visual line move, and i think it is done by basically just inserting line-breaks in the background but display and save it otherwise. (i haven't actually looked at the code though)
The visual line move feature is a critical feature in emacs. Before emacs 23, there are a few packages or code that tries to introduce the visual line move feature (see emacswiki), and longlines-mode is just one of them. However, because it is such a fundamental feature, it is hard for a 3rd-party elisp package to get it correct. They all have major problems…
I think Emacs 23.2's move by visual line feature is great because:
- It fixed a frequently asked feature. (For example, i think ALL editors/IDEs after mid 1990s, move by visual line )
- It fixed a issue that 3rd party elisp packages cannot address well.
Btw, who actually coded the line-move-visual feature? I can't find the info. I like to document it in my emacs pages.
Why line-move-visual is Great
Personally, i find moving by visual line is not just a good feature, but a critical one, with consequences that effect the evolution of language design and thinking, long term. The hard-coded lines is fundamentally introduced by unix and C gang, and brain damaged a whole generation of coders.
I've written about 7 essays addressing this point in the past 10 years. Each 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.
- The Harm of Hard-wrapping Lines. A introduction. (written as a diatribe )
- Tabs versus Spaces in Source Code. Introduces the idea as semantic based formatting vs hard-coded formatting.
- Plain-Text Email Fetish and Unix, RFC, Line Truncation. Shows some connection of the hard-coded habit from unix.
- A Simple Lisp Code Formatter. 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.
- Fundamental Problems of Lisp. Half of the essay discuss the above issues with respect to lisp the language, and consequences.
Flame War with Mark Crispin
hi Mark Crispin,
Mark Crispin wrote:
This is why UNIX and C accomplish things. They were based upon accomplishing something useful rather than promoting an ideology.
maybe you shouldn't use emacs? Emacs is main part of GNU's Not Unix, and the whole lisp culture and thinking is contrary to unix and C.
It sounds like Microsoft Word is more suitable for the sort of work that you do. Perhaps you ought to use Word instead of seeking to make emacs become more like Word.
speaking of Microsoft Word, i wait for dinosaurs like u to die. The question is, can we recruit enough new generation of coders to emacs fast enough before emacs extinguishes.
Mark Crispin wrote:
emacs predates GNU by several years.
I was there at emacs' creation, and I used its predecessors. I had only a very minor role in its software development, but I had an influence on the design of some of the basic commands (I remember, although RMS may have forgotten).
am curious, if you know Daniel Weinreb, and who used emacs first. Am curious just to satisfy a fun quote, about who can claim being the oldest emacs user.
Nobody has been using Emacs longer than I have (I was one of the original beta-testers. I refer here to the original Emacs, written in ITS TECO for the DEC 10.)
[see Daniel Weinreb on Emacs Keybinding]
I see you also have a Wikipedia entry, at [ http://en.wikipedia.org/wiki/Mark_Crispin ] [ https://en.wikipedia.org/wiki/Mark_Crispin ].
Mark Crispin wrote:
│ speaking of Microsoft Word, i wait for dinosaurs like u to die. You seem to have some serious psychological problems. │ The │ question is, can we recruit enough new generation of coders to emacs │ fast enough before emacs extinguishes. If emacs "extinguishes", it will because it no longer provides a benefit that overcomes its demerits. There are many word processors, most of which perform that task quite a bit better than emacs. emacs provides a particular benefit, and fills a niche that is not served by word processors. The world is not made a better place by undermining that benefit in order to transform emacs from a superior text editor to an inferior word processor.
The question is what is superior and inferior.
For example, in this thread, i consider that the move by screen line as a new feature is absolutely good. You disagree, but didn't seem to provide counter to the reasons i gave. You started to cite about me wanting emacs to become Microsoft Word.
I respect your recognized contribution to humanity as a computer programer. However, not sure if you are aware, that i've argued with well known emacs and lisp old timers for the past 10 years. Examples:
- Larry Wall and Cults
- Laziness, Perl, and Larry Wall
- On the Survival Strategies of Larry Wall vs Richard Stallman
- Language, Purity, Cult, and Deception
- “Free” Software Morality, Richard Stallman, Paperwork Bureaucracy
- Why Software Suck
- Lisp-1 vs Lisp-2
- Paul Graham's Infatuation with the Concept of Hacker
- Lambda in Python 3000
- Python, Lambda, Guido: is Language Design Just Solving Puzzles?
You can try also to search newsgroup archive on [ Richard Fateman ] [ https://en.wikipedia.org/wiki/Richard_Fateman ], [ Richard P. Gabriel ] [ https://en.wikipedia.org/wiki/Richard_P._Gabriel ] , [ Kent Pitman ] [ https://en.wikipedia.org/wiki/Kent_Pitman ] , on my conversation with them in comp.lang.lisp.
The point being, doesn't matter how famous or how expert one is about particular subject, he can always be wrong, and statically, they are often quite wrong about many of their opinionated views outside the very narrow field they have expertise a single human animal can possibly achieve, as documented in history. (this counts in for example some big mouthers whom's got strong opinion on everything once they got a Nobel) Also, they tend to be more wrong when they are old, usually happens when it is long past the years they were recognized for.
So, here, we have a argument about a issue of emacs. We disagree.
I have written quite a few criticisms of emacs in the past. They are documented here: http://xahlee.org/emacs/emacs_modernization.html.
Often with suggested solution and sometimes code.
It is my firm belief, that each of my claim or reasons of suggestion can be verified in some scientific way by most reasonable judgments.
To argue, first let's be precise what we are arguing about. Here's few points:
• emacs 23's introduction of line-move-visual feature is good (or bad).
• emacs 23's default of line-move-visual t good (or bad)
• the very concept of move by screen line is good (or bad).
You may disagree with all of them. But to be fruitful in our debate, lets pick just one of the topic, and we can argue about it rationally.
Please don't just claim about how it is like Microsoft Word. That's not a good argument. Because, for example, i can then retort that you are a dinosaur.
Also, don't just say that people are getting dumb. We often hear it from older people, may they be grandpa or college professors, but it is usually uttered as a sigh without much basis. Part of it is simply because people get old and they envy the young. Generally speaking, newer generation are smarter, healthier, more informed, throughout history.
The good old days, my ass. LOL.
Btw, i'm 42. Not exactly the young thing you want to grab.
Am happy to have become acquainted with you. However, i'm sorry i'm not the typical normal people when it comes to human animal relationships and argument resolution. You started a aggressive bitching about a issue i care about, then throw the typical “Microsoft Word” slur when i gave a list of essays i've written in the past 10 years that reason about why i think it is a good feature.