emacs, unix, line truncation, move by screen line


On Jun 4, 6:39 am, brendan.hal...@ul.ie (Brendan Halpin) wrote:
> Attempted thread-jack: why use visual-line-mode instead of
> longlines-mode?

longlines-mode has serious bugs, i believe still so even i haven't used it since emacs 23.1 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 i forgot.

there are 1 or more 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 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

i think Emacs 23.2's move by visual line feature is great because:

• it fixed a frequently asked feature. (e.g. 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 visual line mode? I can't find the info. I like to document it in my emacs pages.


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. See:

• Xah on Programing Languages

See the articles under the Formatting section.

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.


• 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

• Unix, RFC, and 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.

∑ http://xahlee.org/

hi Mark Crispin,

On Jun 4, 11:18 am, 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.


∑ http://xahlee.org/

No comments:

Post a Comment