help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: line-move-visual


From: Xah Lee
Subject: Re: line-move-visual
Date: Wed, 08 Dec 2010 15:11:47 -0000
User-agent: G2/1.0

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
problems...

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
  http://xahlee.org/Periodic_dosage_dir/comp_lang.html

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
  http://xahlee.org/UnixResource_dir/writ/hard-wrap.html

A introduction. (written as a diatribe )

------------------------------

• Tabs versus Spaces in Source Code
  http://xahlee.org/UnixResource_dir/writ/tabs_vs_spaces.html

introduces the idea as semantic based formatting vs hard-coded
formatting.

------------------------------

• Plain-Text Email Fetish
  http://xahlee.org/UnixResource_dir/writ/plain_text.html

• Unix, RFC, and Line Truncation
  http://xahlee.org/UnixResource_dir/writ/truncate_line.html

Shows some connection of the hard-coded habit from unix.

------------------------------

• A Simple Lisp Code Formatter
  http://xahlee.org/emacs/lisp_formatter.html

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
  http://xahlee.org/emacs/syntax_tree_walk.html

Another example of what could happen if unix didn't made people to
think about hard-coded short lines.

------------------------------

• Fundamental Problems of Lisp
  http://xahlee.org/UnixResource_dir/writ/lisp_problems.html

Half of the essay, discuss the above issues with respect to lisp the
language, and consequences.

  Xah
∑ http://xahlee.org/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]