Re: line-move-visual

[Tim X]

Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes:

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

Not at all. It was suggested that mature reliable software that is
maintained by competant, mature and experienced programmers /never/
changes its interface. This implies that change is not only unnecessary,
but cannot occur in a mature system. The implication was that because
visual line mode changes the interface, the developers and maintainers
were immature, inexperienced and arrogant. I reject this assertion that
interfaces cannot change and that any change in an interface
automatically means the software is immature, unreliable and/or
maintained by incompetant developers. I would go further and argue that
in some situations, changing the interface is actually the correct and
responsible thing to do. 

Changing the interface is not the problem, it is how that change is
implemented that is the issue. If we accept a generalisation that
interfaces cannot change, we run the risk of artificially constraining
possibilities and fail to focus on the important challenge of
establishing processes that will allow the itnerface to develop and
mature without undesirable side effects. Arguing that the interface can
never change is over simplifying the situation and encourages a mindsset
where change is feared and raises the real possiblity that the software
will stagnate and fail to either keep pace with evolving technology or
user expectations. 

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

I don't disagree. Different domains have different constraints. However,
just because the domain someone works in has specific constraints does
not mean that those constraints should be automatically applied to other
domains. 

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

I have stated repeatably that I agree that making visual line mode the
default was a mistake. I also agree that the maintainers probably need
to create better channels of communication to get more feedback from end
users. I totally disagree with the arguments that introduction of visual
line mode was a mistake. I totally disagree with the persoanl attacks on
the developers and insinuations regarding their maturity, competance and
experience and charges of arrogance. I totally disagree with absolutes
such as interfaces should never change and defaults should never change.
I do accept that interfaces should be treated in a very conservative
manner and that any change should be considered extremely carefully. I
even have trouble coming up with an example that wold support changing
of defaults. However, I see a big difference between saying that we
should be very conservative regarding change in these areas and saying
that these areas should /never/ change. 

I expect some will respond with "well yes, there are exceptions where
change would be OK if blah blah" etc and "you are being too literal,
there are always exceptions to the rule" etc. In which case, I would say
that it is better to be clearer regarding what is meant. Avoid setting
up 'rules' that deal in absolutes which distract from core issues and
create false constraints. Say that interfaces and defaults should be
treated extremely conservatively and should not change without clear
justification. Once we accept that change is possible in this respect,
we can then focus on how to assess when a change to the interface is
justified, how such changes should be implemented, how end users should
be consulted and how to roll the change out. Denying that change is
possible means that we don't properly consider the implications of the
change and don't establish propper processes for dealing with it.

[snip]

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

I have had files currupted by emacs and I have had files currupted by
VM. In both cases, they were bugs in production versions. However, given
that I've been using emacs pretty much all day, everyday for 15 years, I
do consider it very stable. 

> 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 have had VM fail on a number of occasions and have had it currupt my
mail folder at least once. Yes, it has been mostly very stable and
reliable. However, problems/bugs do occur regardless of how mission
critical you assume it is. Likewise, you cannot make assumptions
regarding how mission critical developers view a system based on a
bug or single decision. 

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

To be honest, while I believe Mark raised a valid issue regarding visual
line mode being the default, I think he over reacted and his somewhat
personal attacks on the emacs developer community only distracted form
the important issues he raised. There have been a couple of suggestions
regarding how he can work around the issue, which he does not seem to
respond to and I suspect that he may be "throwing the baby out with the
bath water". 

> So, changes that can potentially break things are
> *not* ok.  

Sounds nice, but the reality is that any change can potentially break
things. We can certainly establish processes that help mitigate this.
However, we need to first accept that change is possible and sometimes
needed in order to then establish these processes. This is why I reject
the claim that the interface should never change and/or defaults should
never change. 

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

I still think this is all being wildly over stated. We are talking about
one change largely implemented by one developer. We cannot make
assumptions about all the developers and what they do or do not need
based on a single change. Consider the substantial interface changes
that have occured between emacs 22 and emacs 23. Given how stable emacs
has remained despite all these changes, I would suggest the developers
need to be congratulated for doing an excellent job.  

There has been a lot of theorizing about how badly visual line mode will
break things, but I've not actually seen much evidence of people who are
using visual line mode experiencing problems. Furthermore, if you
disable visual line mode, the impact is absolutely nil. 

The issue is not that visual line mode was a mistake, but rather that it
was introduced as a default and that implications of doing so were not
well thought out, especially with respect to keyboard macros etc and
that this change in default was not adequately communicated. 

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

[snip]

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

There is nothing new here. We have always been in this position. Look at
the emacs NEWS files. They contain a section on incompatible lisp
changes. There is always the potential for existing packages to break
with new versions of emacs and it isn't uncommon for packages to need
changes in order to work with a new major version. 

I also think your over stating the situation. The potential problem only
occurs if you enable visual line mode. 

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

Mark's criticism regarding visual line mode being the default is valid.
His heavy does of vitriole against the whole emacs developer community
is not. As I don't know him and have not worked with him, I cannot judge
his credentials as a programmer and would never presume to do so. 

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

That is a fair point. However, I would also suggest that many of the
experienced and active users are also the first ones to adopt or trial
emacs versions. At work, I run emacs 23.1. However, at home and for most
of my personal development work, I run the latest development system,
which I upgrade at least once a week. 

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

That isn't how I interpreted Stefan's response at all. My interpretation
was that he believes, based on feedback, that many users found visual
line mode a beneficial new feature, but he acknowledges that it hasn't
come without some problems. 

I don't understand why you are asking if C-n should move by logical line
or visual line in logical line mode. Isn't this what the difference is
between the two modes? In logical line mode, the behavior is exactly the
same as it has always been - C-n moves by logical line. In visual line
mode, it moves by visual line. I don't see any issue here and there is
no evidence anywhere that I am aware of that proposes any changes to
line movement when not in visual line mode. 

There are two issues I am aware of where it appears there has been a
lack of in-depth analysis. The first and I think most serious is the
impact of visual line mode on existing saved keyboard macros. More
thought is required in this area. Personally, I would be inclined to
somehow restrict macros in such a way that they won't work if the buffer
is in a different line mode to the one it was in when the macro was
defined.

The second issue, which /may/ be a problem is the impact of next-line in
packages people use while also using visual line mode. I would suggest
that both of these are enough justification for not setting visual line
mode as the default - at least not yet. It definitely should have been
introduced as an optional non-default feature. 

Tim

-- 
tcross (at) rapttech dot com dot au