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

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

Re: line-move-visual


From: Mark Crispin
Subject: Re: line-move-visual
Date: Wed, 08 Dec 2010 15:12:09 -0000
User-agent: Alpine 2.00 (OSX 1167 2008-08-23)

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.


reply via email to

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