Re: line-move-visual

[Mark Crispin <mrc@panda.com>]

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.

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