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

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

Re: line-move-visual


From: Uday S Reddy
Subject: Re: line-move-visual
Date: Wed, 08 Dec 2010 15:13:34 -0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4

On 6/13/2010 2:41 AM, Tim X wrote:

Change is not the issue. Change can be positive and is necessary. The
issue is managing that change. Any attempt to enforce a static
unchanging environment will fail.

You are demolishing a strawman. None of us ever said that change is unnecessary. The thought that was in my mind when I wrote the previous message is better expressed as follows:

In the OS & network protocols world /where Mark Crispin comes from/ things can never change essentially.

So, Mark has every right to blow up when things have changed essentially. Emacs devs needed that lesson and, judging from Stefan's last post, I think they continue to need it. Do you disagree? (Don't be too focused on surface niceties and etiquette and all that. Different people have different ways of expressing themselves. The substance is what matters in the end.)

The reason that things can never change in the OS & network protocols world is that all the services interface to other systems and services. So, if you change one thing, however inconsequential it might seem, you can end up breaking everything. Somebody once told me that, if you want to change one line of code in the kernel of an on-board computer system, you have to produce thousands of pages of documentation analyzing how it will affect everything else on the aircraft. It is so hard to do it that it is almost never done.

In the Emacs world, it is easy to think that we are delivering services to the human user, who is clever enough to figure things out. Emacs is a /text editor/ after all. So, change is ok. But the problem is that Emacs is not just a text editor any more. Unbeknownst to the developers, or perhaps even known to them in some instances, it is being used as a critical system component in other applications or services. Emacs has certainly earned the right to be such a component. It is some 30-40 years old. Its core is rock solid. Who has ever had a file corrupted by Emacs? (On the other hand, I have had files corrupted by file servers sold by even reputable companies.) We use Emacs for email in VM, which I regard as mission-critical, because all hell can break loose if a mail folder gets corrupted or somebody can't read their email. We regularly use Emacs to develop code with all kinds additional functionality from editing modes and interfaces to code repositories. If something goes wrong there, other developed software can break, with untold consequences. I am dying to figure out what application Mark Crispin is putting Emacs to that makes it so hard for him to accommodate the line-move-visual change. So, changes that can potentially break things are *not* ok. We don't have to be as diligent as the on-board kernel hackers, but we certainly have to be a lot more careful than we seem to be at the moment. Emacs devs have to grow up into this real world.

Changing the meaning of next-line has consequences far beyond what the Emacs devs have been able to grasp. I have mentioned previously that I found three calls to `next-line' in VM. They were not in VM core, in third party contributions, but try telling that to somebody whose mail folder gets corrupted! Emacs devs might say one should never have used `next-line' in elisp code, but that is not really good enough, is it? Emacs manual never said one *must not* use next-line in elisp code. It only said that there are better ways of doing it. So, an elisp programmer cannot be faulted for using `next-line'.

(As an aside, Microsoft used to say that the problems faced by the users with Windows weren't their fault but rather those of third party device drivers. Microsoft had hoisted complicated protocols on the device driver writers, who couldn't manage them properly. Microsoft has now developed sophisticated driver verification tools - some of the best in the field - to verify that the device drivers satisfy the protocols. Good for them! And good for the users!)

Imagine what I have to say in the next release notes of VM: "Emacs 23 has introduced an incompatible change to the meaning of `next-line' which can cause folder corruption. This release of VM is the first safe version of VM for use with Emacs 23". This doesn't stop other users still using older versions of VM from facing folder corruption. Nor will it stop some downstream distribution from packaging an old version of VM with the later version of Emacs. Is that the kind of situation we want to be in?

Stefan says, perhaps half-jokingly, that he never uses Emacs while being root. Does RMS think the same? Do all the trustees of FSF accept that Emacs is unfit to be used while being root? What other Gnu software is similarly unfit to be used as root? Mark Crispin's criticism has to be taken seriously, even if it comes with a heavy dose of vitriole, because he is a top-level systems programmer who knows better.

When you say that this change has been around for a year and no complaints were raised, you are not being clear about how software changes are propagated. It takes years for changes to go through the pipeline of downstream distributions and even longer for users to upgrade their systems. Smart users who want to play safe are always careful to let the dust settle before upgrading. Our local sys admins haven't even installed Emacs 23.1 yet on our departmental machines. That will probably happen during this summer. If I was a normal user, rather than a developer, I would have probably taken an additional year or so to make the switch. So, these late complaints are the most important ones. They come from the more serious and conservative users. Emacs devs are going to have to face the heat for quite a while to come.

Mark Crispin is not satisfied with Stefan's response. Neither am I, to tell you the truth. When says, "Given the reactions we've seen since Emacs-23.1 was released, I don't regret the decision", he is indicating that he is happy to play to the gallery, and quite an uninformed gallery at that. When I asked "do you want C-n to move by logical line or visual line in the logical line mode", the gallery has been silent. If this is the measure of support needed to introduce incompatible changes in Emacs, then Emacs does seem to be in trouble!

Cheers,
Uday






reply via email to

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