Re: line-move-visual

11 views
Skip to first unread message

Xah Lee

unread,
Jun 4, 2010, 1:49:08 PM6/4/10
to
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/


Mark Crispin

unread,
Jun 4, 2010, 2:18:02 PM6/4/10
to
On Fri, 4 Jun 2010, Xah Lee posted:

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

This is why UNIX and C accomplish things. They were based upon
accomplishing something useful rather than promoting an ideology.

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.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Xah Lee

unread,
Jun 4, 2010, 3:19:47 PM6/4/10
to

hi Mark Crispin,

On Jun 4, 11:18 am, Mark Crispin <m...@panda.com> 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.

LOL!

Xah
http://xahlee.org/


Mark Crispin

unread,
Jun 4, 2010, 10:33:10 PM6/4/10
to
On Fri, 4 Jun 2010, Xah Lee posted:
> maybe you shouldn't use emacs? Emacs is main part of GNU's Not Unix,

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

> and the whole lisp culture and thinking is contrary to unix and C.

emacs was not originally written in LISP. It was many years later that it
was ported to LISP.

Not that I dislike LISP. Quite the contrary; my history with LISP is
longer than with C. I wrote the first IMAP client in LISP, and years
later (1989) reimplemented it in Objective-C.

On the other hand, I acknowledge Richard Gabriel's essay about why "Worse
is Better". I doubt that anyone would be presumptous enough to imply that
Gabriel is ignorant about LISP! He convincingly demonstrates why UNIX and
C won, while ITS and LISP lost. That essay was a particularly bitter pill
to swallow for those of us who spent many years in the MIT/Stanford
environment (nearly 15 years for me); but it was spot-on.

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

I can understand the frustration of being unable to convince a word
processor user to try emacs. Nonetheless, it is unwise to alienate the
core constituency when purposing to expand the constituency.

Xah Lee

unread,
Jun 5, 2010, 6:28:28 PM6/5/10
to
2010-06-04

On Jun 4, 7:33 pm, Mark Crispin <m...@panda.com> wrote:
> On Fri, 4 Jun 2010, Xah Lee posted:
>
> > maybe you shouldn't use emacs? Emacs is main part of GNU's Not Unix,
>
> 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.

Daniel wrote: «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.) »

source: http://groups.google.com/group/comp.emacs/msg/0342e0bc1aa05c0d
2008-06-01 on comp.emacs

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

I see you also have a Wikipedia entry, at http://en.wikipedia.org/wiki/Mark_Crispin

nice.

> > 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 seems 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

for examples:

• Larry Wall and Cults
http://xahlee.org/UnixResource_dir/writ/larry_wall_n_cults.html

• Laziness, Perl, and Larry Wall
http://xahlee.org/UnixResource_dir/writ/perl_laziness.html

• On the Survival Strategies of Larry Wall vs Richard Stallman
http://xahlee.org/UnixResource_dir/writ/wall_stallman.html

• Language, Purity, Cult, and Deception
http://xahlee.org/UnixResource_dir/writ/lang_purity_cult_deception.html

• “Free” Software Morality, Richard Stallman, and Paperwork
Bureaucracy
http://xahlee.org/UnixResource_dir/writ2/FSF_philosophy.html

• Why Software Suck
http://xahlee.org/UnixResource_dir/writ/why_software_suck.html

(Kent Pitman)
• Why You should Not Use The Jargon Lisp1 and Lisp2
http://xahlee.org/emacs/lisp1_vs_lisp2.html

• Paul Graham's Infatuation with the Concept of Hacker
http://xahlee.org/comp/Paul_Graham_language_design.html

you can try also to search newsgroup archive on Richard Fateman,
Richard Gabriel, 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 who'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 writen quite a few criticisms of emacs in the past. They are
documented here:

• Emacs Modernization
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 concep 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. Older people, may
it be grandpa or college professors, tend to say that a lot, but it is
usually uttered as a sigh of life 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.

Xah
http://xahlee.org/


Mark Crispin

unread,
Jun 5, 2010, 10:56:42 PM6/5/10
to
On Sat, 5 Jun 2010, Xah Lee posted:

> am curious, if you know Daniel Weinreb, and who used emacs first.
> Daniel wrote: "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.) "

DLW was there, and was quite a bit closer to the thick of things than I
was. I had returned to complete my undergraduate education in another
state a few months before.

In reading his quote, DLW does not claim to be "the first"; he simply
says that nobody has used it longer than he has.

There was no single person who was "first". I can think of at least a
half dozen individuals without trying who would share the spot with him.
The actual number is probably at least twice that.

I started using emacs within a couple of days of DLW. I knew of the
project (it had started the previous summer). When I started noticing (I
was remote via ARPAnet on a 300 bps dialup) that people were running "E",
instead of what they were running before, I put two and two together at
once and joined the fun.

This would have been December 1976 - January 1977.

emacs was barely usable then, with frequent crashes, but it improved very
quickly. It was also somewhat difficult to use, as I did not have a
cursor-addressed display terminal (yes, it was possible to use it in
"glass teletype" mode). It may have been a couple of months after that
before I finally was able to try emacs in full display mode.

I know that by the spring of 1977 I had access to an ADM-3A which had
cursor addressing...but very little else good to say about it as a display
terminal. I wrote a term paper using emacs on it, at 300 baud. Today,
such torture would probably be banned by UN treaty.

I used the predecessors of emacs for at least a year before DLW arrived.
My macro library, with its symmetry between control and meta that emacs
copied, was an extension of the TECMAC library. TECMAC and another
library called TMACS were the two main streams that became emacs.

Most of emacs' fundamental key bindings came from TECMAC, but there were
significant differences. For example, TECMAC used C-Y C-Y for what in
emacs was first C-X C-R and later became C-X C-F. TMACS' influence was
especially felt in the M-X commands. emacs fused these.

The fundamental behaviors of C-A, C-E, C-N, and C-P were all in TECMAC.
Now that I think about it, I think that they were in ^R mode in TECO
before that. They're very old behaviors.

I'm not certain now - DLW will definitely correct me if I am wrong - but I
am pretty sure that DLW wrote the first clone of emacs. It was on the
Lisp Machine, written in Lisp Machine LISP (a superset of MacLISP; Common
LISP didn't exist yet) and was called EINE (Eine Is Not Emacs). Its
successor was ZWEI.

DLW is a good guy and a very bright programmer.

Uday S Reddy

unread,
Jun 6, 2010, 5:53:32 AM6/6/10
to
On 6/5/2010 11:28 PM, Xah Lee wrote:

> 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

Thank God that some civility has returned to this thread!

> 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 concep of move by screen line is good (or bad).

No, I don't think that these are the questions that this debate is about. (When we start debating what the debate is about, we should realize that we are hopelessly knotted up in circles!)

Emacs 23 has a *visual line mode* and a *logical line mode* (the default mode that you have whenever the visual-line-mode is /not/ turned on).

Everybody understands and expects that C-n moves by visual line in the visual line mode. The question is, do you want it to move by visual line or logical line in the *logical line mode*?

Let me repeat: do you want C-n to move by visual line or logical in the *logical line mode*?

In the megabytes of debate that has gone on on this issue, I haven't seen a single point mentioned as to why it should move by visual line in the logical line mode. Yet, that is the default in Emacs 23! Worse, it *changes* the semantics of C-n which as, Mark Crispin points out, has been here the 70's.

So, there are three things that an old-timer is annoyed about:

1. Change of established semantics.

2. Inconsistency.

3. Pointlessness.

Coupled with these real technical issues, there are the attitudinal problems of holier-than-thou, smarter-than-thou and modern-than-thou and what have you. In another part of this thread, we have also seen the astonishing idea that the developers don't have to care about what the users want/need. If that is the attitude that open source developers take, then I will be the first to give up open source!

Cheers,
Uday

David Kastrup

unread,
Jun 6, 2010, 5:39:25 AM6/6/10
to
Uday S Reddy <uDOTsD...@cs.bham.ac.uk> writes:

> Coupled with these real technical issues, there are the attitudinal
> problems of holier-than-thou, smarter-than-thou and modern-than-thou
> and what have you.

Everybody is free to join the discussions on the Emacs developer lists.
Those who choose not to help with the work don't get to criticize the
results. A common democratic principle.

> In another part of this thread, we have also seen the astonishing idea
> that the developers don't have to care about what the users
> want/need. If that is the attitude that open source developers take,
> then I will be the first to give up open source!

An excellent idea. The Free Software Foundation cares principally about
free software, not open source.

Open source sports the notion of creating superior software by
significantly different processes than common.

Free software is based on the premise of empowering the recipient of
software to change and adapting it according to his own needs.

Pampering to the needs of users who are not interested in changing and
adapting the software according to their needs is not a major priority.

Feel free to fork any free software which does not behave like you want
it: you have the power. You are not dependent on upstream developers.

If you tie yourself to distribution channels that take this power from
you effectively, you are doing it by choice. If you think you are in a
suitable majority, tell your distribution channel to change the upstream
decision for you if you don't feel like discussing this in a civilized
manner on the developer discussion lists created for that purpose.

--
David Kastrup

Uday S Reddy

unread,
Jun 6, 2010, 9:55:22 AM6/6/10
to
On 6/6/2010 10:39 AM, David Kastrup wrote:

> Free software is based on the premise of empowering the recipient of
> software to change and adapting it according to his own needs.
>
> Pampering to the needs of users who are not interested in changing and
> adapting the software according to their needs is not a major priority.
>
> Feel free to fork any free software which does not behave like you want
> it: you have the power. You are not dependent on upstream developers.

Good point. But not all users have the time or the ability to do their own changing or forking or even significant customization. Allowing the *possibility* of users to change things is not the same as *expecting* them to change things.

In this particular instance, the customization needed is not a big deal: set line-move-visual to nil. Almost everybody can do it. But the time they had to spend in discovering that they needed to change it is what has been significant. (In fact, after this thread started, I began to wonder if VM might be vulnerable to the problem as well, and went and checked if there were calls to next-line anywhere. There were three of them!)

It is not for nothing that we have ideas like standards and backward-compatibility. It didn't seem to me that the discussion on the developers list showed much appreciation to these issues, despite them having been raised repeatedly.

By the way, I think that the Emacs 23 visual-line-mode and word wrapping are a great addition to Emacs. A civilized way of dealing with longlines has long been needed. But the default setting of line-move-visual is an independent issue to that.

Cheers,
Uday

Tassilo Horn

unread,
Jun 6, 2010, 11:21:03 AM6/6/10
to
Uday S Reddy <uDOTsD...@cs.bham.ac.uk> writes:

Hi Uday,

> In this particular instance, the customization needed is not a big
> deal: set line-move-visual to nil. Almost everybody can do it. But
> the time they had to spend in discovering that they needed to change
> it is what has been significant.

IMO, the first thing a new emacs user should learn is using the help
facilities. So after seeing that `C-n' moved point not to the next
(logical) line as it always did should be a reflexive `C-h C-n':

,----[ C-h k C-n ]
| C-n runs the command next-line, which is an interactive compiled Lisp function
| in `simple.el'.
|
| It is bound to C-n, <down>.
|
| (next-line &optional ARG TRY-VSCROLL)
|
| Move cursor vertically down ARG lines.
| [...]
| If the variable `line-move-visual' is non-nil, this command moves
| by display lines. Otherwise, it moves by buffer lines, without
| taking variable-width characters or continued lines into account.
| [...]
|
| If you are thinking of using this in a Lisp program, consider
| using `forward-line' instead. It is usually easier to use
| and more reliable (no dependence on goal column, etc.).
`----

> (In fact, after this thread started, I began to wonder if VM might be
> vulnerable to the problem as well, and went and checked if there were
> calls to next-line anywhere. There were three of them!)

As you can see in the docs above, `next-line' wasn't the right function
to call from lisp even before visual line movement.

> By the way, I think that the Emacs 23 visual-line-mode and word
> wrapping are a great addition to Emacs. A civilized way of dealing
> with longlines has long been needed. But the default setting of
> line-move-visual is an independent issue to that.

I agree with all of that.

Bye,
Tassilo

Mark Crispin

unread,
Jun 6, 2010, 1:24:42 PM6/6/10
to
On Sun, 6 Jun 2010, Uday S Reddy posted:

> In the megabytes of debate that has gone on on this issue, I haven't seen a
> single point mentioned as to why it should move by visual line in the logical
> line mode. Yet, that is the default in Emacs 23! Worse, it *changes* the
> semantics of C-n which as, Mark Crispin points out, has been here the 70's.

And breaks key macros.

> So, there are three things that an old-timer is annoyed about:
> 1. Change of established semantics.
> 2. Inconsistency.
> 3. Pointlessness.

4. Breaking long-standing key macros and procedures, which in turn leads
to file corruption based upon the current screen width (= "random and
unpredictable").

> Coupled with these real technical issues, there are the attitudinal problems
> of holier-than-thou, smarter-than-thou and modern-than-thou and what have
> you.

It seems to be a common problem among some Gen-X types. John Xenakis (a
colorful character if ever there was one!) writes a good essay related to
the topic:

http://www.generationaldynamics.com/cgi-bin/D.PL?d=ww2010.i.java080701

> In another part of this thread, we have also seen the astonishing idea
> that the developers don't have to care about what the users want/need. If
> that is the attitude that open source developers take, then I will be the
> first to give up open source!

This attitude has always been a problem, but in the past it would be
corrected. In a lab where everybody was under one roof, the users would
gang up (often with the lead developer) and discipline the offending young
developer.

Today, the only recourse is to spawn a fork. The problem is that each
fork erodes the credibility of open source. The classic example is BSD,
which committed suicide by fork.

Mark Crispin

unread,
Jun 6, 2010, 2:17:19 PM6/6/10
to
On Sun, 6 Jun 2010, Uday S Reddy posted:
> In this particular instance, the customization needed is not a big deal: set
> line-move-visual to nil. Almost everybody can do it. But the time they had
> to spend in discovering that they needed to change it is what has been
> significant.

An additional significant burden is the need to update .emacs files on
dozens of machines in order to keep common functionality. There is a huge
scalability problem.

There are things that you can do to avoid 2^n synchronization, such as
designating one system as having the "master" copy from which all others
are updated. But then, each time you encounter a problem on a "slave"
that necessitates a change to the slave, you must:
[1] make the corresponding change to the master
[2] test on the master
[3] test on at least one other slave
[4] push the update from the master to all other slaves

The fun and laughter proceeds apace if you don't have access to the master
at that point of time. Then you have to make a note that you needed this
change, and subsequently find that note when you can get to the master
again.

And all this presumes that it's a set that is harmless in old versions.
The true joy comes in when the change has an unintended bad effect in
some other slave and you didn't catch it in step [3].

The best case wastes a great deal of time, repeated for each affected
user. The worst case is a nightmare.

Part of the maturing process is learning to recognize when a simple
cookbook solution is neither simple nor cookbook nor solution.

> (In fact, after this thread started, I began to wonder if VM
> might be vulnerable to the problem as well, and went and checked if there
> were calls to next-line anywhere. There were three of them!)

I hope that you didn't have any corrupted files as a result.

> It is not for nothing that we have ideas like standards and
> backward-compatibility. It didn't seem to me that the discussion on the
> developers list showed much appreciation to these issues, despite them having
> been raised repeatedly.

A clueless developer is a very bad thing.

> By the way, I think that the Emacs 23 visual-line-mode and word wrapping are
> a great addition to Emacs. A civilized way of dealing with longlines has
> long been needed. But the default setting of line-move-visual is an
> independent issue to that.

Let me be clear; I have no objection whatsoever to the feature having been
added and made available.

The issue is it having been made the default, particularly in modes where
it is pointless.

It is also important to realize that there are many editors that handle
long lines in a "civilized" way. However, in certain circumstances, it is
desirable and necessary to handle long lines the "uncivilized" way; and it
is a feature of emacs that it can do that.

No amount of raving about how the "civilized" way is better will change
those circumstances. The only effect of enforcing the "civilized" way is
to render emacs unsuitable for those applications.

For example, I have a scripted procedure which depends upon emacs'
"uncivilized" behavior. It is followed by individuals who never use emacs
for any other reason. I have no control over what version they use, but
that had always been alright since every program that ever called itself
emacs worked the same way with it. Until now.

I don't know what I'm going to about that procedure. I'm probably going
to have to write a program and/or a sed script to replace it. This is
unfortunate, since an advantage of the emacs method was that the user
could see what the procedure was doing.

All because of clueless developers who broke emacs in version 23.

Thad Floryan

unread,
Jun 6, 2010, 9:07:58 PM6/6/10
to
On 6/6/2010 11:17 AM, Mark Crispin wrote:
> [...]

> All because of clueless developers who broke emacs in version 23.

This is OT so I'll keep it short. Similar braindamage recently with
Fedora where a developer stated "I don't particularly care how UNIX
has always worked."

Refs:

<http://linux.slashdot.org/story/09/11/18/2039229/Fedora-12-Lets-Users-Install-Signed-Packages-Sans-Root-Privileges>

<http://linux.slashdot.org/story/09/11/20/1241231/Fedora-12-Package-Installation-Policy-Tightened>

<https://www.redhat.com/archives/fedora-announce-list/2009-November/msg00012.html>

<https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01445.html>

Developer's blog:

<http://blogs.gnome.org/hughsie/2009/11/20/the-fedora-12-installing-saga/>

Mark Crispin

unread,
Jun 6, 2010, 10:53:26 PM6/6/10
to
On Sun, 6 Jun 2010, Thad Floryan posted:

> This is OT so I'll keep it short. Similar braindamage recently with
> Fedora where a developer stated "I don't particularly care how UNIX
> has always worked."

Wow.

I've dealt with broken "improvements" in RedHat/Fedora before; they don't
seem to have a very good review process for functionality changes. The
two that I remember the most are making flock() return ENOLCK for an NFS
file (instead of no-op) and getaddrinfo() doing a reverse DNS lookup for
the ai_canonname return value. In both cases, the developer insisted that
the change was a "fix", never mind all the applications that were broken
by it. Eventually, both of these changes were reverted after a huge hue
and cry.

This one takes the cake.

I don't know which amazes me more, the fact that such an ill-conceived
change was made in the first place, or the developer's reaction when
called to account.

Uday S Reddy

unread,
Jun 7, 2010, 4:19:27 AM6/7/10
to
On 6/6/2010 4:21 PM, Tassilo Horn wrote:

>> In this particular instance, the customization needed is not a big
>> deal: set line-move-visual to nil. Almost everybody can do it. But
>> the time they had to spend in discovering that they needed to change
>> it is what has been significant.
>
> IMO, the first thing a new emacs user should learn is using the help
> facilities. So after seeing that `C-n' moved point not to the next
> (logical) line as it always did should be a reflexive `C-h C-n':

Note that we are talking about the old emacs users, not the new ones. (The C-n
compromise was apparently made to help the new Emacs users!)

An old emacs user might see a long logical line only very rarely, and he might
take quite a while to realize that anything had changed. As Mark Crispin
explained, he had to purposefully go looking for it by doing M-<large number>
C-n on a number of Emacs versions to discover that something had changed. I
had to hear of Mark's experience before I started suspecting that there could
be vulnerabilities in VM. (I accept that using `next-line' in elisp code is
not a clever thing to do, but we live in the world of "free software" where
lots of people contribute.) How much elisp code might still be there that has
this vulnerability? We won't know. Just as an experiment, I went to the
emacs-23.2 lisp directory and did a grep for next-line. There were 91 hits.
How many of them are safe?

I myself noticed the changed C-n very quickly because I work with Emacs
debugger a lot, where long lines are common. First I thought it was kind of
cute, then I got annoyed because I had to find new ways of skipping over
bytecode pieces that span lots of lines, and now I am alarmed as I think of the
vulnerabilities that might exist in elisp code. If I used keyboard macros a
whole lot (which I don't), then I would have been even more affected.

However, it didn't occur to me that I could freely set `line-move-visual' to
nil and all the problems would disappear. I thought that the setting was
probably mixed up with word wrapping and visual-line-mode and all that stuff
that I care about. It was only after Stefan himself said:

"Yes, it's inconsistent, yes, it's a compromise, no not everybody likes it.
Then (setq line-move-visual nil) in your .emacs and live happily ever after."

... only then did I understand that the emacs devs had done a completely
pointless thing that I could easily revert.

Cheers,
Uday

Tim X

unread,
Jun 7, 2010, 4:39:18 AM6/7/10
to
David Kastrup <d...@gnu.org> writes:

> Uday S Reddy <uDOTsD...@cs.bham.ac.uk> writes:
>
>> Coupled with these real technical issues, there are the attitudinal
>> problems of holier-than-thou, smarter-than-thou and modern-than-thou
>> and what have you.
>
> Everybody is free to join the discussions on the Emacs developer lists.
> Those who choose not to help with the work don't get to criticize the
> results. A common democratic principle.
>

Common democratic principal! What a load of crap.

Anyone can criticise any decision at any time. Whether the
maintainers want to take any notice is another matter.

For the record, I dislike the default of enabling move by visual lines
rather than logical ones. However, as it is trivial to revert behavior
back to the old default, this whole thread is largely poinless moaning
that is unlikely to change anything.

I do agree that if you are someone who is going to get upset about
changes that you don't agree with, then you should participate in the
devel discussions. If you don't want to, then you are just going to have
to suck it up and either accept it or use something else. Moaning about
it without putting in any effort to find out why the change was made and
what discussions took place indicates low emotional maturity and/or
someone who just wants to have a childish dummy spit because somehting
in their world changed without their permission.

Despite the fact I don't agree witht he change in default behavior, I
also want to make it very clear, I DO NOT support what has been
posted regarding the motivation, care and competancy of the emacs
developers and maintainers. To those of you who have done this I would
say that making all sorts of assumptions regarding the motivations and
considerations of the devel team without actually looking at what
discussions did take place is an unjustified and unwarranted attack on
those few people who put in the hard word to develop and maintain this
free software. It is a cheap dishonarable swipe. It lumps all the
developers together as if they are all in agreement regarding every
change made and ignores the effort put in to try and get the right
outcome and do the difficult job of balancing many different views.

If you don't like what they have done, either

a) get on the devel list and present a case and maybe build support
to have the default changed.,
b) Make the trivial config change to restore the old behavior and
move on
C) Use an old version and maintain it yourself the way you want
d) Give up and go away.

Tim


--
tcross (at) rapttech dot com dot au

Tim X

unread,
Jun 7, 2010, 4:46:42 AM6/7/10
to
Uday S Reddy <uDOTsD...@cs.bham.ac.uk> writes:

> On 6/6/2010 10:39 AM, David Kastrup wrote:
>
>> Free software is based on the premise of empowering the recipient of
>> software to change and adapting it according to his own needs.
>>
>> Pampering to the needs of users who are not interested in changing and
>> adapting the software according to their needs is not a major priority.
>>
>> Feel free to fork any free software which does not behave like you want
>> it: you have the power. You are not dependent on upstream developers.
>
> Good point. But not all users have the time or the ability to do their own changing or forking or even significant customization. Allowing the *possibility* of users to change things is not the same as *expecting* them to change things.
>
> In this particular instance, the customization needed is not a big deal: set line-move-visual to nil. Almost everybody can do it. But the time they had to spend in discovering that they needed to change it is what has been significant. (In fact, after this thread started, I began to wonder if VM might be vulnerable to the problem as well, and went and checked if there were calls to next-line anywhere. There were three of them!)
>

The change was clearly documented in the NEWS file, which also explained
how to restore the old behavior. Any user who upgrades to a new version
and is too lazy to check the NEWS file (and the PROBLEMS file for that
matter), especially after observing unexpected or different behavior
gets what they deserve.

Andreas Politz

unread,
Jun 7, 2010, 6:21:07 AM6/7/10
to
Tim X <ti...@nospam.dev.null> writes:

> If you don't like what they have done, either
>
> a) get on the devel list and present a case and maybe build support
>

Wouldn't this contradict the cause, now that line-move-visual is the
*default* ?

Heh.

-ap

Stefan Monnier

unread,
Jun 7, 2010, 12:23:52 PM6/7/10
to
> The change was clearly documented in the NEWS file, which also explained
> how to restore the old behavior.

Admittedly, this file is loong. We should probably try to make
a "revert to old defaults" section somewhere so it's easier to find
those things.


Stefan

Leo

unread,
Jun 8, 2010, 4:52:54 AM6/8/10
to
On 2010-06-07 09:19 +0100, Uday S Reddy wrote:
> "Yes, it's inconsistent, yes, it's a compromise, no not everybody
> likes it. Then (setq line-move-visual nil) in your .emacs and live
> happily ever after."
>
> ... only then did I understand that the emacs devs had done a
> completely pointless thing that I could easily revert.

And that usually is the outcome of long discussions.

The whole new feature is almost useless (by adding its + and -) and I
wished they had been more careful and selective in putting things in
emacs releases.

Leo

Joseph Brenner

unread,
Jun 9, 2010, 4:23:25 PM6/9/10
to

Stefan Monnier <mon...@iro.umontreal.ca> writes:

Actually... if you're planning of having a section like that,
I'd suggest there's already a bigger problem.

Joseph Brenner

unread,
Jun 9, 2010, 5:38:23 PM6/9/10
to

David Kastrup <d...@gnu.org> writes:
> Uday S Reddy <uDOTsD...@cs.bham.ac.uk> writes:
>
>> Coupled with these real technical issues, there are the attitudinal
>> problems of holier-than-thou, smarter-than-thou and modern-than-thou
>> and what have you.
>
> Everybody is free to join the discussions on the Emacs developer lists.
> Those who choose not to help with the work don't get to criticize the
> results. A common democratic principle.

So... if I want to avoid breakage-on-upgrade on my system, I need to
become a member of the development process of:

emacs
linux kernel
ubuntu (and presumably debian)
x windows

Not to mention:

apache
postgresql
perl
mh-e
mh

...and much more.

If I thought everyone in the free and/or open world really believed this,
I would've voted with my feet a long time ago.

(Maybe you should stop pretending you're our spokesman, huh?)

Jim Diamond

unread,
Jun 9, 2010, 9:34:56 PM6/9/10
to
["Followup-To:" header set to gnu.emacs.help.]

On 2010-06-09 at 18:38 ADT, Joseph Brenner <do...@kzsu.stanford.edu> wrote:
>
> David Kastrup <d...@gnu.org> writes:
>> Uday S Reddy <uDOTsD...@cs.bham.ac.uk> writes:
>>
>>> Coupled with these real technical issues, there are the attitudinal
>>> problems of holier-than-thou, smarter-than-thou and modern-than-thou
>>> and what have you.
>>
>> Everybody is free to join the discussions on the Emacs developer lists.
>> Those who choose not to help with the work don't get to criticize the
>> results. A common democratic principle.
>
> So... if I want to avoid breakage-on-upgrade on my system, I need to
> become a member of the development process of:
>
> emacs
> linux kernel
> ubuntu (and presumably debian)
> x windows
>
> Not to mention:
>
> apache
> postgresql
> perl
> mh-e
> mh
>
> ...and much more.

And you can imagine how the usefulness of those discussions would
rapidly drop to zero if everyone who used emacs (or any of your other
examples) joined the (respective) development discussions.

David: the message (about fundamental features changing being a Bad
Thing) was delivered in a less than gentle way, but I think you should
re-consider the idea, as opposed to the way it was delivered.
Further, your comment "Those who choose ... A common democratic
principle." is just plain wrong. But I assume you know that.

Cheers.
Jim

Uday S Reddy

unread,
Jun 10, 2010, 6:12:19 AM6/10/10
to
>> Uday S Reddy <uDOTsD...@cs.bham.ac.uk> writes:
>>
>>> Coupled with these real technical issues, there are the attitudinal
>>> problems of holier-than-thou, smarter-than-thou and modern-than-thou
>>> and what have you.
>
> Despite the fact I don't agree witht he change in default behavior, I
> also want to make it very clear, I DO NOT support what has been
> posted regarding the motivation, care and competancy of the emacs
> developers and maintainers. To those of you who have done this I would
> say that making all sorts of assumptions regarding the motivations and
> considerations of the devel team without actually looking at what
> discussions did take place is an unjustified and unwarranted attack on
> those few people who put in the hard word to develop and maintain this
> free software. It is a cheap dishonarable swipe. It lumps all the
> developers together as if they are all in agreement regarding every
> change made and ignores the effort put in to try and get the right
> outcome and do the difficult job of balancing many different views.

Oh, dear! Sorry for the misunderstanding. I didn't mean to imply that
the Emacs developers have shown the "attitudinal problems" that I
mentioned. It had more to do with the attitudes expressed by some of
the "spokesmen" here (in Joseph Brenner's good words).

In themselves, the devs have been nothing less than professional and
polite, either here or on the emacs-devel list. They do an incredible
amount of work, quite silently, and we all owe a great debt of gratitude
to them!

The thinking behind the line-move-visual decision went something like
this. If C-n moves by logical lines then the new users would be
confused. If it moves by visual lines then the experienced users would
be bothered. But we have a flag whereby experienced users can revert to
the old behavior. The new users won't know enough to set a flag. So,
let us go with the default that helps out the new users. See this
thread for example:

http://thread.gmane.org/gmane.emacs.devel/101551/focus=101560

or tens of other threads that discussed line-move-visual.

I don't think there is any reason to attribute arrogance or carelessness
on the part of the developers in reaching that decision. At worst, it
was a technical mistake in thinking that both the defaults are equally
bad. Or, perhaps an error of judgement that the experienced users will
know enough to change the default.

---

Now that this thread has gone for this long and still seems to have some
life left, why don't we come up with some constructive ideas? I have a
few of them here, mostly colored by my experience with maintaining VM.

The first suggestion I have is that the Emacs developers can find a way
to consult the user community about potential changes. It is not
reasonable to expect that all users should take part in the developers
discussion in order to provide their input. It seems like an additional
imposition on top of all the work that the developers already do, but
having an open discussion about visible behavior changes ahead of time
can save from unnecessary heartburn later on. I do this kind of thing
regularly for VM. See this discussion for example:

http://groups.google.com/group/gnu.emacs.vm.info/browse_thread/thread/1297bd3ab1de78d9/2361a430ee7e7bc3?lnk=raot#2361a430ee7e7bc3

The second suggestion, which Stefan seems to be thinking about already,
is to clearly label changes in the NEWS file. This is also something I
have been doing in VM. See, for example, the NEWS file here:

https://launchpad.net/vm/+download

I am constantly irritated by the fact that some of the downstream
distributions omit the the NEWS files from installations. I have
resorted to putting the NEWS file as an independent download on the web
site so that the downstream users can get it directly. I think we
should try and impress upon the downstream guys the importance of NEWS
files.

A third suggestion is that we should start thinking of Emacs as
mission-critical software. "Text editor" is a lousy description
which has long been out of date. It is really platform on which a
number of critical services are delivered, for development of projects
or for running of teams and organizations. A lot rides on it and any
changes that potentially cause corruption of files or data can be quite
serious.

Finally, and I might be a bit OTT here, I think we should think of free
software as community-owned software. It is not developer-owned
software (despite the aberration caused by the existence of FSF as a
copyright-owner). Lots of people contribute, and they come and go. The
software will live on for long after they are gone. Free software isn't
"free-to-fork" software, even though the right to fork exists as a last
resort and as a foundation for everything else. If that right needs to
be exercised, it is a signal that the community-ownership of the
software has broken down and that is not good for any of us.

Cheers,
Uday

Stefan Monnier

unread,
Jun 10, 2010, 9:43:46 AM6/10/10
to
> The thinking behind the line-move-visual decision went something like
> this. If C-n moves by logical lines then the new users would be
> confused. If it moves by visual lines then the experienced users would
> be bothered. But we have a flag whereby experienced users can revert to
> the old behavior. The new users won't know enough to set a flag. So,
> let us go with the default that helps out the new users. See this
> thread for example:

Choosing defaults is very difficult indeed. You can never please
everyone. In this specific case, I'm the main guy to blame: I wrote the
original patch for line-move-visual (oddly enough, since it touches
parts of the code I still am not at all familiar with), mostly because
it seemed it would be important for proper support of word-wrap (which
I didn't care for much, but many users cared about it).

After writing the patch, I tried it out, mostly for debugging purposes,
and much to my surprise I discovered that I actually liked it.

Yes, it occasionally doesn't do what I want, but in practice, it does
what I want more often than the previous case:
- when no line wraps, it either makes no difference, or it works
slightly better because it correctly accounts for
variable-pitch fonts.
- when lines are long (typically the "single-line paragraph" text coming
from people who either use word-wrap or longlines-mode or an editor
that behaves similarly, but can also happen in many other cases like
binary files, or mechanically-generated files), the new behavior is
much better (how did you move to "that spot I see about 10
visual-lines down from point" in a single logical line in
previous Emacsen?).
- when the buffer mostly fits without wrapping, except for a few
exceptions, then yes, the new behavior is less good for those
wrapped-lines. In my particular case, such lines are usually (very
minor) bugs anyway, so it's not that important, but I understand that
some people get annoyed. And of course, if you use C-100 C-n instead
of M-g M-g 100 RET to move to the line 100 (I personally use C-s 100
instead ;-), you'll be disappointed, and if you use keyboard macros
you'll also be disappointed.

Depending on your particular circumstances, the second case will only
rarely happen whereas the third will be very common, so you'll be
really annoyed. Sorry about that. Please (setq line-move-visual nil)
in your .emacs and/or try to come up with some idea how we could keep
the advantages in cases 1 and 2 without suffering in case 3.


Stefan

Uday S Reddy

unread,
Jun 10, 2010, 11:17:18 AM6/10/10
to
Stefan Monnier wrote:

> Choosing defaults is very difficult indeed. You can never please
> everyone. In this specific case, I'm the main guy to blame: I wrote the
> original patch for line-move-visual (oddly enough, since it touches
> parts of the code I still am not at all familiar with), mostly because
> it seemed it would be important for proper support of word-wrap (which
> I didn't care for much, but many users cared about it).

Isn't word-wrap the ideal solution for dealing with the single-line paragraphs
that you mention in the second bullet point below?

If line-move-visual is nil by default, the users that care about 1 and 2 can
set it to t, can't they? It is the same issue from the other side of the
fence. They don't need the default set in a particular way to get their behaviour.

Moreover, the people dealing with single-line paragraphs (me being one of them)
will normally use visual-line-mode, which does visual line motion anyway. So,
they are not affected by the default at all.

So, this particular decision doesn't seem to be all that difficult.

Cheers,
Uday


des...@verizon.net

unread,
Jun 10, 2010, 11:44:02 AM6/10/10
to
Stefan Monnier <mon...@iro.umontreal.ca> writes:

>> The thinking behind the line-move-visual decision went something like
>> this. If C-n moves by logical lines then the new users would be
>> confused. If it moves by visual lines then the experienced users would
>> be bothered. But we have a flag whereby experienced users can revert to
>> the old behavior. The new users won't know enough to set a flag. So,
>> let us go with the default that helps out the new users. See this
>> thread for example:
>
> Choosing defaults is very difficult indeed. You can never please
> everyone. In this specific case, I'm the main guy to blame:

Good, then I have something to contribute to this thread.

Nice work and I support the idea of making this a default.

For me, it was easy to spot the new behavior, and I assumed I
would find a description and override in the NEWS file.

So far I've found no reason to do so.

I hope the complainers get a full refund of all the money they
paid for your hard work and nothing else.

Richard Kettlewell

unread,
Jun 10, 2010, 12:24:20 PM6/10/10
to
Stefan Monnier <mon...@iro.umontreal.ca> writes:

> Depending on your particular circumstances, the second case will only
> rarely happen whereas the third will be very common, so you'll be
> really annoyed. Sorry about that. Please (setq line-move-visual nil)
> in your .emacs and/or try to come up with some idea how we could keep
> the advantages in cases 1 and 2 without suffering in case 3.

Perhaps an 'auto' setting where the behavior depended on the buffer
mode? For instance equivalent to 'nil' in programming language modes
and to 't' in text editing modes.

--
http://www.greenend.org.uk/rjk/

Mark Crispin

unread,
Jun 10, 2010, 12:57:01 PM6/10/10
to
On Thu, 10 Jun 2010, Uday S Reddy posted:

> A third suggestion is that we should start thinking of Emacs as
> mission-critical software.

It amazes me that anyone would think otherwise.

> It is really platform on which a
> number of critical services are delivered, for development of projects
> or for running of teams and organizations. A lot rides on it and any
> changes that potentially cause corruption of files or data can be quite
> serious.

As the kids say, "well, duh!"

This discussion is rapidly leading to "is free software suitable as
mission-critical software?".

Some people would be more comfortable is the answer is "no". Then they
don't have to deal with the responsibility of mission-critical software.

> Finally, and I might be a bit OTT here, I think we should think of free
> software as community-owned software. It is not developer-owned
> software (despite the aberration caused by the existence of FSF as a
> copyright-owner).

The notion of "community-owned software" works as ideology, but not as
reality. If emacs was really community-owned software, I as a community
member could revert the change in the official distribution sources. And
then there could be revert wars ala Wikipedia.

That existed once upon a time in the mid-1970s, at MIT (the ITS systems)
and elsewhere. It didn't end well.

The dichotomy between "the cathedral and the bazaar" that ESR postulated
doesn't really exist. The full-fledged bazaar option doesn't scale and
never actually happened. It's just two types of cathedrals, one run by a
pope and the other run by a board of laymen.

But even the laymen become power-corrupted.

> Free software isn't
> "free-to-fork" software, even though the right to fork exists as a last
> resort and as a foundation for everything else. If that right needs to
> be exercised, it is a signal that the community-ownership of the
> software has broken down and that is not good for any of us.

That is certainly true. Again, BSD serves as an example.

Another sign of a process breakdown is when a developer's answer to user
complaints about changes in a new version is "so just run the old
version". The need to revert to an old version means that the new version
is broken.

The corrolary to this is that the standard developer's answer to
complaints about bugs in an old version is "upgrade to the new version".
This only works if the upgrade is a viable option.

Developers can't have it both ways. If they create a new version that is
unacceptable to some portion of the user community, they they have
effectively forked the software.

Responsible developers figure this out after a while. It takes maturity.
Generally, they want their users to be using one, and only one, version;
and they do what is necessary to ensure that there are no barriers to
upgrade.

Since user interface surprise is a barrier to upgrade, they make sure
there aren't any such surprises.

In the real world, people get fired for inflicting surprises in
mission-critical software.

Uday S Reddy

unread,
Jun 10, 2010, 2:38:17 PM6/10/10
to
Mark Crispin wrote:

> The notion of "community-owned software" works as ideology, but not as
> reality. If emacs was really community-owned software, I as a community
> member could revert the change in the official distribution sources.
> And then there could be revert wars ala Wikipedia.

Exactly! By "community-owned", I don't mean community-developed. There needs
to be control and discipline etc in the development team. Otherwise, there
will be chaos, and mission-critical fitness will go out of the window.

By community ownership, I only mean that all the people that have a stake in
the system have a voice in the matter and we all feel ownership of the system.
When the community is divided, as seems to be the case on this issue, the
developers have to make a decision and move on.

In any case, I think we have reached a point where you and Stefan need to talk
to each other directly and sort it out. In my humble opinion, it is easy to
argue that the current default was ill-chosen. But it is not so easy to argue
that it should be changed. If we change it, then we face all the same issues
all over again affecting the other users that are depending on the current
default. So, it seems best to leave things as they are and make a note of all
the lessons learned.

> But even the laymen become power-corrupted.

I think that is a bit of an exaggeration. They have a responsibility to bear
and sometimes they get carried away.

> Since user interface surprise is a barrier to upgrade, they make sure
> there aren't any such surprises.

Yes, that point is well-made. But, the same argument now suggests that the
default should not be changed yet again.

Cheers,
Uday


Thad Floryan

unread,
Jun 10, 2010, 3:06:46 PM6/10/10
to
On 6/10/2010 6:43 AM, Stefan Monnier wrote:
> [...]

> some people get annoyed. And of course, if you use C-100 C-n instead
> of M-g M-g 100 RET to move to the line 100 (I personally use C-s 100
> instead ;-), you'll be disappointed, and if you use keyboard macros
> you'll also be disappointed.
> [...]

Hmmm, I've had the following line

(global-set-key "\M-#" 'goto-line)

in my .emacs for so many years (think decades) as a quick'n'easy method
to go to a specific line number mentioned in a compiler warning/error
regardless where I'm presently in the buffer.

I.e., "C-u 8 ESC #" goes to line 8; "C-u 1234 ESC #" goes to line 1234.

How is/will that be affected (if C-n and C-p are affected)?

Stefan Monnier

unread,
Jun 10, 2010, 3:53:24 PM6/10/10
to
>> Choosing defaults is very difficult indeed. You can never please
>> everyone. In this specific case, I'm the main guy to blame: I wrote the
>> original patch for line-move-visual (oddly enough, since it touches
>> parts of the code I still am not at all familiar with), mostly because
>> it seemed it would be important for proper support of word-wrap (which
>> I didn't care for much, but many users cared about it).
> Isn't word-wrap the ideal solution for dealing with the single-line
> paragraphs that you mention in the second bullet point below?

Only for the display part: it doesn't help navigation.

> So, this particular decision doesn't seem to be all that difficult.

Leaving line-move-visual as nil would have been an easy decision to
satisfy old users who already like Emacs. But setting it to t (without
switching all the way to visual-line-mode) seemed like
a good compromise.

Given the reactions we've seen since Emacs-23.1 was released,
I don't regret the decision.


Stefan

Stefan Monnier

unread,
Jun 10, 2010, 3:57:34 PM6/10/10
to
>> A third suggestion is that we should start thinking of Emacs as
>> mission-critical software.
> It amazes me that anyone would think otherwise.

Based on the amount of bugs in Emacs, the wishy-washy semantics of most
of its operations, the quick&dirty half-solutions seen in most of its
packages, it amazes me that someone would consider Emacs as
mission-critical ;-)


Stefan "who never uses Emacs while root"

Tassilo Horn

unread,
Jun 10, 2010, 6:02:12 PM6/10/10
to
Stefan Monnier <mon...@iro.umontreal.ca> writes:

> - when no line wraps, it either makes no difference, or it works
> slightly better because it correctly accounts for
> variable-pitch fonts.

> - when lines are long [...], the new behavior is much better (how did


> you move to "that spot I see about 10 visual-lines down from point" in
> a single logical line in previous Emacsen?).

I agree, and with the macro exception I'm in favour of operating on
visual lines by default. But what I don't understand is why there are
two levels of operating on visual lines: line-move-visual and
visual-line-mode. IMO, the former is confusing, because C-a/e (and
probably others) still operate on logical lines.

I guess, that's because VLM is more invasive, i.e. keys get bound to new
functions. But then, why not drop VLM altogether and make
`move-beginning/end-of-line' obey line-move-visual, too?

Bye,
Tassilo

Tassilo Horn

unread,
Jun 10, 2010, 6:10:23 PM6/10/10
to
Stefan Monnier <mon...@iro.umontreal.ca> writes:

> Stefan "who never uses Emacs while root"

I think you forgot to add the subordinate clause "...because he uses
TRAMP's sudo method in an already running emacs server to access files
where he has no permissions for", right?

Bye,
Tassilo

Evans Winner

unread,
Jun 10, 2010, 6:48:08 PM6/10/10
to
In my opinion, the question should never be what new users
of Emacs want. What new users want is an editor that is 5%
better than notepad.exe because that is per-force the limit
of their imagination. They generally do no know 1% of what
Emacs can do, so are not in a position to intelligently
decide what the defaults should be. They /should/ want to
rely on experienced users for that, and they should be
willing to spend the extra tiny bit of effort up-front to
learn the reasoning behind it. If they aren't, then Emacs
isn't for them. Let them go. Changing defaults to whatever
makes the least friction for those who switch to Emacs is
not a service to new users; the principle is that people
tend to stick with what they learn first, so dumbed-down
defaults produces dumbed-down users, who will, after a few
months or years, show up on emacs-devel demanding even more
dumbed-down defaults, because that would make it even easier
for the next generation of Microsoft/IBM/CUA refugees.

It sometimes surprises me to find that even some experienced
users of Emacs don't use and even sometimes don't know how
to use keyboard macros. The name Emacs does, after all,
come from the phrase "Editor MACroS." It is a fundamental
part of the user experience. The question with regards to
new users and line-move-visual is whether the slight savings
in initial cognitive friction comes and the price of making
it more difficult for new users to learn to create and use
typical line-at-a-time-type keyboard macros. I don't claim
to know the answer to this particular question, but I think
the principle above is the right one to consider in this
kind of case.

Uday S Reddy

unread,
Jun 10, 2010, 7:56:27 PM6/10/10
to
On 6/10/2010 11:02 PM, Tassilo Horn wrote:

>
> I guess, that's because VLM is more invasive, i.e. keys get bound to new
> functions.

Hi Tassilo, Can you or anybody else give us some examples of how
visual-line-mode is invasive? I haven't been able to understand this point.

Cheers,
Uday

Tassilo Horn

unread,
Jun 10, 2010, 8:48:54 PM6/10/10
to
Uday S Reddy <uDOTsD...@cs.bham.ac.uk> writes:

>> I guess, that's because VLM is more invasive, i.e. keys get bound to
>> new functions.
>
> Hi Tassilo, Can you or anybody else give us some examples of how
> visual-line-mode is invasive? I haven't been able to understand this
> point.

Not invasive from a user's point of view, but from a implementation
point of view. With visual-line-mode, C-e is not bound to
`move-end-of-line' but to `end-of-visual-line', and the same applies to
other bindings. It's possible that this redefinition of standard keys
leads to unexpected behavior, for example when using [remap
move-end-of-line].

Not sure if that's really problematic, so that's why I've asked.

Bye,
Tassilo

Mark Crispin

unread,
Jun 11, 2010, 7:56:06 PM6/11/10
to
On Thu, 10 Jun 2010, Uday S Reddy posted:
> By community ownership, I only mean that all the people that have a stake in
> the system have a voice in the matter and we all feel ownership of the
> system. When the community is divided, as seems to be the case on this
> issue, the developers have to make a decision and move on.

The problem is that nobody ever asked the existing users whether or not
they wanted this global change foisted upon them. Rather, it was done
unilaterally, and the individuals responsible are saying "See! Some
people like it! It was a good change."

This sort of thing happened in the past as well. The difference was that
there was accountability in the past that is absent today.

> In my humble opinion, it is
> easy to argue that the current default was ill-chosen. But it is not so easy
> to argue that it should be changed. If we change it, then we face all the
> same issues all over again affecting the other users that are depending on
> the current default. So, it seems best to leave things as they are and make
> a note of all the lessons learned.

I agree that we are probably screwed, and royally so.

I have a new task on my list: replace emacs in the procedures for my
target audience since emacs is no longer suitable for that purpose. I
simply can not tell these users "make sure that you set line-move-visual
to nil"; they would have no clue what that means. More likely than not, I
will end up being obliged to write a program for the task; and there will
be one less way those users will be exposed to emacs.

One of the advantages of the "software tools" mindset of the past was that
you did not have to write a program for every task. Instead, you could
leverage the existing tools. That falls apart when those tools are
corrupted so that they no longer can be relied upon to produce predictable
results.

>> But even the laymen become power-corrupted.
> I think that is a bit of an exaggeration. They have a responsibility to bear
> and sometimes they get carried away.

Every young programmer wants to put his own mark on things. The problem
is that these changes are frequently ill-considered and sometimes have bad
consequences.

>> Since user interface surprise is a barrier to upgrade, they make sure there
>> aren't any such surprises.
> Yes, that point is well-made. But, the same argument now suggests that the
> default should not be changed yet again.

Yup. We're probably screwed.

Wojciech Meyer

unread,
Jun 11, 2010, 8:17:21 PM6/11/10
to
Mark Crispin <m...@panda.com> writes:

> On Thu, 10 Jun 2010, Uday S Reddy posted:
>> By community ownership, I only mean that all the people that have a
>> stake in the system have a voice in the matter and we all feel
>> ownership of the system. When the community is divided, as seems to
>> be the case on this issue, the developers have to make a decision
>> and move on.

Well it is certainly possible, one can use mailing list and the NEWS
file, which was suggested before.

> This sort of thing happened in the past as well. The difference was
> that there was accountability in the past that is absent today.

What sort of acountability, I think unhappy `customers' is enough
punishment.

> I have a new task on my list: replace emacs in the procedures for my
> target audience since emacs is no longer suitable for that purpose. I
> simply can not tell these users "make sure that you set
> line-move-visual to nil"; they would have no clue what that means.
> More likely than not, I will end up being obliged to write a program
> for the task; and there will be one less way those users will be
> exposed to emacs.

What kind of Emacs users are they? Isn't possible to place on every
machine a stub containing: (setq line-move-visual nil).

>
> One of the advantages of the "software tools" mindset of the past was
> that you did not have to write a program for every task. Instead, you
> could leverage the existing tools. That falls apart when those tools
> are corrupted so that they no longer can be relied upon to produce
> predictable results.

It is ever more true now.

>
>>> But even the laymen become power-corrupted.
>> I think that is a bit of an exaggeration. They have a
>> responsibility to bear and sometimes they get carried away.
>
> Every young programmer wants to put his own mark on things. The
> problem is that these changes are frequently ill-considered and
> sometimes have bad consequences.

There is nothing wrong in being young and creative, that makes often
things better. Young people often do care more about things then Senior
Architects, they are also more flexible for changes.

The reason why this setting wasn't kept by default is to fix the
fundamental problem, without additional cost of keeping this setting
hidden. People have full rights to receive the fixes like this, as you
have full rights to complain about them. This is part of the game, IMHO
Emacs does not change that often, and really keeps things the same, just
because there is nothing to fix apart from things that need to be
changed in order to guarantee future of Emacs.

Wojciech

Uday S Reddy

unread,
Jun 13, 2010, 8:46:42 AM6/13/10
to
On 6/10/2010 8:57 PM, Stefan Monnier wrote:

>
> Based on the amount of bugs in Emacs, the wishy-washy semantics of most
> of its operations, the quick&dirty half-solutions seen in most of its
> packages, it amazes me that someone would consider Emacs as
> mission-critical ;-)

Mission-critical software isn't necessarily perfect software. What software is?

Mission-critical software requires a clean architecture, attention to
fundamental notions of reliability, a design that can isolate any potential
problems and an ability to recover from them. Even though you seem to think
the semantics of the Emacs operations is wishy-washy (and I have pointed out
some of them to you myself), the Emacs manuals - both the user's manual and the
programming manual - are of quite high-quality and do an excellent job of
defining things. We can generally spot the portions that are wishy-washy or
too complicated for comfort and stay away from them. The use of Lisp with type
safety and memory safety means that even inexperienced programmers can usually
deliver code of decent quality. The various fail-safe mechanisms, such as
autosave, backups, movemail etc, help for failure recovery. The large,
professional user base, along with its age, imply that most problems have been
identified and fixed a long time ago. The small developer community might also
mean that it grows at a manageable pace (even though that seems to be changing
now).

When I was trawling through the net, I found somebody say that nobody ever lost
an email message in VM (the Emacs package for email that I currently maintain).
When I enquired about it, it was pretty much true. There is only one known
instance of mail folder corruption, which happened due to the unibyte-multibyte
transition of Emacs around the same time that Kyle Jones was retiring from VM.
So, the transition was apparently half-done and wasn't discovered until much
later.

In comparison, I have lost loads of emails in Microsoft tools, lost files or
changes to files in the Office Suite, had files damaged by Sun-Microsoft file
servers, and had damaging system crashes due to hardware/device driver faults.
On the whole, Emacs has been among the most reliable of all the tools I use.
And, I suspect that must be true for almost all of us here. So, please do
own up to this proud heritage!

>
> Stefan "who never uses Emacs while root"

I guess you will have to amplify this point for us to draw the right
conclusions from it.

Cheers,
Uday

Mark Crispin

unread,
Jun 13, 2010, 1:23:45 PM6/13/10
to
On Sat, 12 Jun 2010, Wojciech Meyer posted:

> Well it is certainly possible, one can use mailing list and the NEWS
> file, which was suggested before.

Please read the first chapter of the Hitchhiker's Guide to the Galaxy to
understand the flaw in that reasoning.

>> This sort of thing happened in the past as well. The difference was
>> that there was accountability in the past that is absent today.
> What sort of acountability, I think unhappy `customers' is enough
> punishment.

Apparently not, if the "customers" are told that it's their fault for not
being on the development list.

> What kind of Emacs users are they? Isn't possible to place on every
> machine a stub containing: (setq line-move-visual nil).

There include people who never use emacs, except to follow the procedure
that I outline (which is literally a cookbook "do these steps exactly").
I have no control or access to the machines in question.

Perhaps I should have written a program to begin with. But it was so much
simpler to leverage upon emacs back in the days when emacs had a reliable
interface. Now that it no longer does, I'm now forced to write the
program.

> There is nothing wrong in being young and creative, that makes often
> things better. Young people often do care more about things then Senior
> Architects, they are also more flexible for changes.

Yes, but they lack the wisdom and experience of their elders. This in
turn leads them to address complex problems with simple solutions that
backfire (sometimes disastrously).

> The reason why this setting wasn't kept by default is to fix the
> fundamental problem,

Yeah, right. The "fundamental problem" that CTRL/A, CTRL/E, CTRL/N,
CTRL/P, etc. moved to predictable places in the file no matter what the
screen width, and thus could be relied upon for a cookbook procedure.

We can't have predictability and reliability. We have to do pretty-pretty
to be just like Word, and destroy the one attribute that made emacs
superior to other choices.

Bletch.

This wouldn't have been a problem had the arrow keys been changed to the
new semantics and CTRL-A/E/N/P been left alone. The new semantics are
even arguably right for arrow keys (although I would go further and say
that they should also treat tabs as the equivalent number of spaces). It
isn't as if we're still in the 1970s and have keyboards without arrow
keys.

Mark Crispin

unread,
Jun 13, 2010, 1:26:40 PM6/13/10
to
On Sun, 13 Jun 2010, Uday S Reddy posted:

> Mission-critical software requires a clean architecture, attention to
> fundamental notions of reliability, a design that can isolate any potential
> problems and an ability to recover from them.

To this, also add predictability.

Mission critical software doesn't deliver different results just because
the screen width is different.

Alan Mackenzie

unread,
Jun 13, 2010, 4:56:30 PM6/13/10
to
In comp.emacs Mark Crispin <m...@panda.com> wrote:
> On Sat, 12 Jun 2010, Wojciech Meyer posted:
>> Well it is certainly possible, one can use mailing list and the NEWS
>> file, which was suggested before.

> Please read the first chapter of the Hitchhiker's Guide to the Galaxy to
> understand the flaw in that reasoning.

Please feel free to suggest a way the development team could have
canvassed users, particularly the vast majority who don't keep up with
project mailing lists. It seems like a difficult problem.

> Apparently not, if the "customers" are told that it's their fault for
> not being on the development list.

It seems like a difficult problem.

>> What kind of Emacs users are they? Isn't possible to place on every
>> machine a stub containing: (setq line-move-visual nil).

> There include people who never use emacs, except to follow the procedure
> that I outline (which is literally a cookbook "do these steps exactly").
> I have no control or access to the machines in question.

> Perhaps I should have written a program to begin with. But it was so much
> simpler to leverage upon emacs back in the days when emacs had a reliable
> interface. Now that it no longer does, I'm now forced to write the
> program.

It seems you're exaggerating your predicament ever so slightly. I'd
guess you could code up the replacement program (in elisp? in sed? in
whatever?) in less time than you've spent discussing the problem here.

It's far from obvious that this change (line-visual-mode being set) is a
Bad Thing. Without it, moving around things like log files with 300
character lines was an utter pain. I'd suggest it was more of a pain
than the one you're suffering, because it hit users using Emacs in its
principal way of working, rather than in special cases in some obscure feature
(keyboard macros).

since Emacs 23, I haven't felt any need whatsoever to restore l-v-m to nil,
and I haven't seen anybody else asking for it.

>> There is nothing wrong in being young and creative, that makes often
>> things better. Young people often do care more about things then
>> Senior Architects, they are also more flexible for changes.

> Yes, but they lack the wisdom and experience of their elders. This in
> turn leads them to address complex problems with simple solutions that
> backfire (sometimes disastrously).

Hence the best team for writing something contains both
stuck-in-the-groove maturity and feckless youth. Not that the Emacs team
is lacking in solid wisdom.

>> The reason why this setting wasn't kept by default is to fix the
>> fundamental problem,

> Yeah, right. The "fundamental problem" that CTRL/A, CTRL/E, CTRL/N,
> CTRL/P, etc. moved to predictable places in the file no matter what the
> screen width, and thus could be relied upon for a cookbook procedure.

Now you've got to take screen width into account. Big deal.

And it was dashed near impossible to move easily to the middle of long,
long lines. I suspect this need to be commoner than using keyboard
macros on long lines.

> We can't have predictability and reliability. We have to do
> pretty-pretty to be just like Word, and destroy the one attribute that
> made emacs superior to other choices.

You're exaggerating at least a little bit here. There are lots and lots
of attributes that make Emacs superior, some of them in contention with
some others. You could easily enough amend your instructions, prefixing
them with "M-: (setq visual-line-mode nil)". Or you could rewrite the
thing (what does it do, exactly?) in elisp or whatever.

> Bletch.

> This wouldn't have been a problem had the arrow keys been changed to
> the new semantics and CTRL-A/E/N/P been left alone. The new semantics
> are even arguably right for arrow keys (although I would go further and
> say that they should also treat tabs as the equivalent number of
> spaces). It isn't as if we're still in the 1970s and have keyboards
> without arrow keys.

The arrow keys are a long way away from the home position on the
keyboard. You're surely not suggesting rebinding those four key
sequences to something else?

> -- Mark --

--
Alan Mackenzie (Nuremberg, Germany).

Jim Diamond

unread,
Jun 13, 2010, 8:42:29 PM6/13/10
to

Why not? Presumably (*) the idea of having long lines and moving to
the next visual line (as the default) is to placate word-processor
refugees, who are probably used to using arrow keys (regardless of how
far they are from the home position) and not interested in using
Ctrl-A,E,N,P.

(*) Wild speculation, since I didn't read the discussion on the
developer list. Mea culpa.

Jim

Uday S Reddy

unread,
Jun 14, 2010, 6:49:36 AM6/14/10
to
Alan Mackenzie wrote:

> It's far from obvious that this change (line-visual-mode being set) is a
> Bad Thing. Without it, moving around things like log files with 300
> character lines was an utter pain. I'd suggest it was more of a pain
> than the one you're suffering, because it hit users using Emacs in its
> principal way of working, rather than in special cases in some obscure feature
> (keyboard macros).

If line-move-visual was nil by default, would you have been able to set it to t
in order to move around the log files?

Cheers,
Uday

Alan Mackenzie

unread,
Jun 14, 2010, 1:16:14 PM6/14/10
to

WADR, that's a silly question. This entire thread has been solely about
default settings, as are many discussions on the devlopers' mailing list.

However, the fact is that I didn't actually set line-visual-mode in any
Emacs before 23. That suggests I either wasn't aware of this setting, or
the pain it caused me, whilst real, didn't cross some sort of (fairly
high) threshold. I honestly can't remember any more.

When using Emacs as a full screen editor (how it's used most of the
time), a key binding is needed to go to the next/previous visual line.
Using C-p/C-n (or <up>/<down>) seems as good a choice as any.

> Cheers,
> Uday

Uday S Reddy

unread,
Jun 14, 2010, 1:34:23 PM6/14/10
to
Alan Mackenzie wrote:

>
>> If line-move-visual was nil by default, would you have been able to set
>> it to t in order to move around the log files?
>
> WADR, that's a silly question. This entire thread has been solely about
> default settings, as are many discussions on the devlopers' mailing list.

Sorry if it sounded silly. The setting of the default to t was precisely
targeted to help people like you.

Neither the setting nor the functionality existed before Emacs 23. So, you
didn't miss anything. But, after having added this functionality, I think the
developers believed that people like you might not have been able to discover
the new functionality on your own, unless it was made the default. Are you
agreeing with that assessment?

Other than changing defaults, is there some other form of "advertising" the
Emacs devs could have used to bring it to your attention?

Cheers,
Uday

David Kastrup

unread,
Jun 14, 2010, 2:16:55 PM6/14/10
to
Uday S Reddy <uDOTsD...@cs.bham.ac.uk> writes:

> Alan Mackenzie wrote:
>
>>
>>> If line-move-visual was nil by default, would you have been able to set
>>> it to t in order to move around the log files?
>>
>> WADR, that's a silly question. This entire thread has been solely about
>> default settings, as are many discussions on the devlopers' mailing list.
>
> Sorry if it sounded silly. The setting of the default to t was
> precisely targeted to help people like you.
>
> Neither the setting nor the functionality existed before Emacs 23.
> So, you didn't miss anything. But, after having added this
> functionality, I think the developers believed that people like you
> might not have been able to discover the new functionality on your
> own, unless it was made the default. Are you agreeing with that
> assessment?

It will be interesting to see where you are heading. You are aware that
Alan is the maintainer of cc-mode?

--
David Kastrup

Patrick May

unread,
Jun 14, 2010, 2:23:34 PM6/14/10
to
Alan Mackenzie <a...@muc.de> writes:
> It's far from obvious that this change (line-visual-mode being set) is
> a Bad Thing. Without it, moving around things like log files with 300
> character lines was an utter pain. I'd suggest it was more of a pain
> than the one you're suffering, because it hit users using Emacs in its
> principal way of working, rather than in special cases in some obscure
> feature (keyboard macros).

Keyboard macros are far from obscure. I use them daily at least.

>> Yeah, right. The "fundamental problem" that CTRL/A, CTRL/E, CTRL/N,
>> CTRL/P, etc. moved to predictable places in the file no matter what
>> the screen width, and thus could be relied upon for a cookbook
>> procedure.
>
> Now you've got to take screen width into account. Big deal.

It is a big deal when it breaks existing code. Backwards
compatibility is important.

> And it was dashed near impossible to move easily to the middle of
> long, long lines.

C-u <some number> right-arrow

Sincerely,

Patrick

------------------------------------------------------------------------
http://www.softwarematters.org
Large scale, mission-critical, distributed OO systems design and
implementation. (C++, Java, Common Lisp, Jini, middleware, SOA)

Stefan Monnier

unread,
Jun 14, 2010, 4:28:00 PM6/14/10
to
>> principal way of working, rather than in special cases in some obscure
>> feature (keyboard macros).
> Keyboard macros are far from obscure.

Indeed.

>> And it was dashed near impossible to move easily to the middle of
>> long, long lines.
> C-u <some number> right-arrow

How convenient!
Say you're in a window and want to go down 3 visual lines on the same
long logical line. What number do you use? Ok, let's make it easier
and say that you happen to know that the window is 76-chars wide.
So 76 by 3? quick? quick?
Now let's do that again but with 13 lines, where you don't actually know
it's "13": you first have to count it.
The best I could come up with, is C-76 C-f and then C-x z z z ... until
you reach the line.

Now this all becomes a lot more interesting once you add word-wrap into
the mix, or TABs, or bytes displayed \NNN, or the presence of various
fonts and/or font-sizes on that long line, or variable-pitch fonts, ...

Clearly visual line movement is really handy in such long lines.
So rather than "C-u <some number> right-arrow", the better answer would
have been: M-x visual-line-mode RET C-n ...


Stefan "who reached for the mouse in all those cases, tho
typically only after first unconsciously hitting C-n
a few times and then realizing that C-n jumped way
further than intended"

Pascal J. Bourguignon

unread,
Jun 15, 2010, 2:54:18 AM6/15/10
to
Stefan Monnier <mon...@iro.umontreal.ca> writes:

>>> principal way of working, rather than in special cases in some obscure
>>> feature (keyboard macros).
>> Keyboard macros are far from obscure.
>
> Indeed.
>
>>> And it was dashed near impossible to move easily to the middle of
>>> long, long lines.
>> C-u <some number> right-arrow
>
> How convenient!
> Say you're in a window and want to go down 3 visual lines on the same
> long logical line. What number do you use? Ok, let's make it easier
> and say that you happen to know that the window is 76-chars wide.
> So 76 by 3? quick? quick?

240. You can refine later.

> Now let's do that again but with 13 lines, where you don't actually know
> it's "13": you first have to count it.

Let's say you can't even count the lines!

You can always, and only with emacs, type:

M-: (forward-char (/ (- (progn (end-of-line) (point)) (progn (beginning-of-line) (point))) 2)) RET


> The best I could come up with, is C-76 C-f and then C-x z z z ... until
> you reach the line.

> Now this all becomes a lot more interesting once you add word-wrap into
> the mix, or TABs, or bytes displayed \NNN, or the presence of various
> fonts and/or font-sizes on that long line, or variable-pitch fonts, ...

Well, C-f C-n is all you need. I mean, keep C-f pressed until the
cursor reaches the column you want, you don't even need to count
76. And keep C-n pressed until the cursor reaches the line you want.


> Stefan "who reached for the mouse in all those cases, tho
> typically only after first unconsciously hitting C-n
> a few times and then realizing that C-n jumped way
> further than intended"

WFM. So far.

--
__Pascal Bourguignon__ http://www.informatimago.com/

Uday S Reddy

unread,
Jun 15, 2010, 4:42:30 AM6/15/10
to
On 6/15/2010 7:54 AM, Pascal J. Bourguignon wrote:

>
> Well, C-f C-n is all you need. I mean, keep C-f pressed until the
> cursor reaches the column you want, you don't even need to count
> 76. And keep C-n pressed until the cursor reaches the line you want.

Except that pressing control-key for that long with your pinky is a health risk!

But I feel this discussion is tangential. Most of us accept that visual line
movement is a /good/ idea and we find it useful in lots of contexts. We are
grateful for Stefan & co for thinking of it and implementing it.

The question is really whether it should have been made the default.

Every time I narrowed down to that issue in this thread, the participants have
fallen silent (first Xah Lee then Tim Cross, Alan Mackenzie and Stefan
himself). I guess there is no good answer to it.

There is no need for us to beat a dead horse. If the developers accept that it
is a bad idea to introduce backward-incompatible changes for flimsy reasons,
Emacs will be a more useful system for all of us than it currently is.

Fortunately, nothing major is going to fall apart as a result of `next-line'
changing its meaning. But I hope that we can arrest this trend right here so
that we don't have to put up with more pain in future.

Cheers,
Uday

Tim X

unread,
Jun 15, 2010, 5:26:13 AM6/15/10
to
Uday S Reddy <uDOTsD...@cs.bham.ac.uk> writes:

This sentiment I agree with. The default for line-move-visual should
have been nil not t, especially as there are some things that still need
more thought (i.e. macros) and if for no other reason, to give
maintainers of other packages time to fix potentially broken code.

The introduciton of this facility was in itself a good idea. How it has
been introduced was not.

Tim

--
tcross (at) rapttech dot com dot au

David Kastrup

unread,
Jun 15, 2010, 5:30:29 AM6/15/10
to
Uday S Reddy <uDOTsD...@cs.bham.ac.uk> writes:

> The question is really whether it should have been made the default.
>
> Every time I narrowed down to that issue in this thread, the
> participants have fallen silent (first Xah Lee then Tim Cross, Alan
> Mackenzie and Stefan himself). I guess there is no good answer to it.

There is no simple answer. And there is no point in working on the
aspects of a complex answer where it is not relevant.

The relevant place is the developer list.

> There is no need for us to beat a dead horse. If the developers
> accept that it is a bad idea to introduce backward-incompatible
> changes for flimsy reasons, Emacs will be a more useful system for all
> of us than it currently is.

That's beating a dead horse, and an imaginary one as well.

> Fortunately, nothing major is going to fall apart as a result of
> next-line' changing its meaning. But I hope that we can arrest this
> trend right here so that we don't have to put up with more pain in
> future.

You are not going to stop development of Emacs single-handedly, and you
will not be "arresting" any trend without working with developers when
the design decisions are being discussed and made.

Venting may be fun, but it will not change things.

--
David Kastrup

Tim X

unread,
Jun 15, 2010, 5:38:18 AM6/15/10
to
Uday S Reddy <uDOTsD...@cs.bham.ac.uk> writes:

> On 6/15/2010 7:54 AM, Pascal J. Bourguignon wrote:
>
> The question is really whether it should have been made the default.
>
> Every time I narrowed down to that issue in this thread, the participants have
> fallen silent (first Xah Lee then Tim Cross, Alan Mackenzie and Stefan
> himself). I guess there is no good answer to it.
>

WTF. I believe I've responded to every single one of your posts directed
to me.

I've lost count of how many times I've posted in this thread saying
that I DO NOT AGREE WITH IT BEING MADE THE DEFAULT. I agree with the
functionality and I agree with introducing changes that change the
existing semantics of next-line etc in order to provide the valuable
addition of visual line editing (which BTW I seem to remember you or
Mark rejecting outright). I suggest you need to take some of your own
advice and go back and read the posts again.

Stefan Monnier

unread,
Jun 15, 2010, 9:45:25 AM6/15/10
to
> Every time I narrowed down to that issue in this thread, the participants
> have fallen silent (first Xah Lee then Tim Cross, Alan Mackenzie and Stefan
> himself). I guess there is no good answer to it.

I did give you the answer: I tried it and found to my surprise that
I liked it, so I suggested it and people said "no way", then they tried
it and some people hated it, while others really liked it.

So in the end it was a judgment call, and I decided that the added
convenience of being able to deal with very-long-lines without having to
change mode was more important. I.e. I decided that case 3 (in my
earlier long post about it) was less common and less important.


Stefan

David Kastrup

unread,
Jun 15, 2010, 9:57:06 AM6/15/10
to
Stefan Monnier <mon...@iro.umontreal.ca> writes:

I should think that changing to logical mode when recording and
replaying macros would be an improvement. I can't imagine anybody
wanting visual mode in that case.

There is already one such change: vertical movement does not use vscroll
in order to go smoothly through vertical material when macro recording
or playback is active.

--
David Kastrup

J.

unread,
Jun 15, 2010, 12:31:54 PM6/15/10
to
Another easier way is to search for a word in the point of the line
you want to go, and search for it with C-s word

Alan Mackenzie

unread,
Jun 15, 2010, 12:51:21 PM6/15/10
to
In comp.emacs Uday S Reddy <uDOTsD...@cs.bham.ac.uk> wrote:
> On 6/15/2010 7:54 AM, Pascal J. Bourguignon wrote:

> But I feel this discussion is tangential. Most of us accept that
> visual line movement is a /good/ idea and we find it useful in lots of
> contexts. We are grateful for Stefan & co for thinking of it and
> implementing it.

> The question is really whether it should have been made the default.

Yes. That is a very difficult question. Most contentious issues
discussed on the developers' list are about changing defaults. This was
one of these.

> Every time I narrowed down to that issue in this thread, the
> participants have fallen silent (first Xah Lee then Tim Cross, Alan
> Mackenzie and Stefan himself). I guess there is no good answer to it.

Ooh, talk about trolling! ;-) I have "fallen silent" because I've
nothing much fresh to say.

> There is no need for us to beat a dead horse. If the developers accept
> that it is a bad idea to introduce backward-incompatible changes for
> flimsy reasons, Emacs will be a more useful system for all of us than
> it currently is.

Normally I'd find myself arguing strongly in the camp of the
"traditionalists" when fighting over a change in defaults. For this
particular change, I'm ambivalent. The hassle with directly editing long
lines is, I believe, more painful than that of navigating keyboard macros
through them. Somebody had to decide this issue, and that somebody was
Stefan. I think, on balance, he made the right choice. I wouldn't have
been complaining if he had decided the opposite.

> Fortunately, nothing major is going to fall apart as a result of
> `next-line' changing its meaning. But I hope that we can arrest this
> trend right here so that we don't have to put up with more pain in
> future.

"Trend"? You are getting polemic! Emacs will continue to evolve
steadily, and some of the changes will cause you minor pain, as they will
me. You're surely used to tweaking your .emacs on every major release,
so what's new?

> Cheers,
> Uday

Uday S Reddy

unread,
Jun 15, 2010, 2:32:14 PM6/15/10