Re: line-move-visual

[Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk>]

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