Re: line-move-visual

[Tim X <timx@nospam.dev.null>]

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

> On 6/14/2010 1:46 AM, Tim X wrote:
>
>> 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.... 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.
>
> Sorry, Tim.  Your rejection would carry some weight if you mentioned the
> situations where changing the interface is "the correct and responsible" thing
> to do.
>
> You also seem to believe that the `line-move-visual' issue did not present
> such a situation where changing the interface was the correct and responsible
> thing to do.  So, I am not sure what your point is, other than providing some
> political support to the developers.
>

OK, fair criticism. I have muddied the waters too much by trying to
address to many issues in a sigle thread. I should probably have put
things in different threads to avoid confusion. I also should have been
more careful with some terminology and phrasing. I will attempt to clarify.

The issues I've tried to address are

    1. The suggestion that interfaces for mature software packages never
    change and that such change means the software is immature or poorly
    maintained. 
    2. The issue of line-move-visual and whether it in itself is a bad
    idea or whether the way it was implemented was a mistake
    3. The frequently personal, overly general and somewhat arrogant
    criticisms of emacs maintainers based largely on unsubstantiated
    assumptions. 

1. While we would like to believe interfaces of mature software packages
never change, this simply isn't reality. If it were, we would always
have backwards compatibility, which we don't. Likewise, it would not be
necessary for programs to use version numbering schemes that incorporate
this information. For example, the Apache scheme uses a format of
'x.y.z' where 'x' indicates significant interface changes that are not
backwards compatible, 'y' indicates a version with interface changes
that are extensions and are backwards compatible and 'z' indicates a
patch. In this context, interface can refer to either API changes or UI
changes.  

While I cannot think of specific examples of interface changes in emacs,
I can certainly recall changes in many other mature packages. For
example, Apache has changed the interface for external modules, Java has
changed its interface for core classes, Microsoft has changed some of
its low level OS interfaces, breaking backwards compatibility for 16 bit
programs and Linux has changed its interface in a number of areas. With
this last one, I have run into issues with a driver I used to use that
is no longer compatible with current 2.6.x kernels. 

I have maintained that interface changes are not something that should
be done unnecessarily. The interface should be treated conservatively
and changes should be avoided where possible. However, I think it is a
mistake to ignore or deny the possibility of interface change because
doing so results in failing to understand and consider the consequences.
This is necessary to know how to properly manage such changes and
minimize impact. It is also necessary because different domains have
different requirements and constraints. For these reasons, I reject
blanket statements that say the interface of mature software packages
must never change. 

> Regarding your questions, yes, I do regard /all/ changes to *existing*
> behavior of mature software systems as bad.  Under exceptional circumstances,
> they could be the *lesser evil* and then we accept them as being unfortunately
> necessary.
>

Right. However, this doesn't fit with the claim of /never/ changing or
with the simplistic view that a change in interface indicates software
that is immature. 

> This does not mean that you can't add new features or extend the existing
> behavior.  Extend it as much as you please, without changing what already
> exists.
>

Agree. Extension is not what I would call change as it doesn't usually affect
backwards compatibility. However, in some cases, most notably user
interfaces, extensions and enhancements can be seen as a change that
breaks backwards compatibility because it modifies the interface to such
an extent that the user feels they no longer recognize it or know how to
use the system despite the fact core operations and APIs have not been
modified. However, this is an edge case. Adding functionality etc
usually doesn't have the level of impact as modifying what already
exists. 

> The Emacs NEWS file currently does not make any distinction between *changes*,
> meaning changes to the existing behavior, and *extensions* (or improvements or
> new features).  All of them are generically labelled as "Changes" (meaning
> changes to the software system, not changes to the behavior of features).
> This is probably a hangover from the time when the file might have been called
> a ChangeLog, rather than NEWS.  Please don't confuse "changes" in this generic
> sense to be actual changes.
>

Hmmm, I don't think I agree. While it could be possible to improve the
labelling, its nowhere as bad as you indicate. Here are the top level
headings from the current NEWS file for the dev version (these basic
headings have been in all the NEWS files I've seen for the past 15
years)

* Installation Changes in Emacs 24.1
* Startup Changes in Emacs 24.1
* Changes in Emacs 24.1
* Editing Changes in Emacs 24.1
* Changes in Specialized Modes and Packages in Emacs 24.1
* New Modes and Packages in Emacs 24.1
* Incompatible Lisp Changes in Emacs 24.1
* Lisp changes in Emacs 24.1
* Changes in Emacs 24.1 on non-free operating systems

>> 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.
>
> These two paragraphs suggest that you don't really know what the issue is.
> Perhaps you should read the manual sections on line-move-visual and
> visual-line-mode  and try them out before discussing them?
>

That was poor expression and haste on my part. I meant line-move-visual
and not visual-line-mode. I suspect the confusion is with the general
use of 'mode' and the emacs specific definition of a buffer mode. 

After what you wrote, I thought it would be a good idea to check my
facts and experiment a bit. My understanding wasn't too far off the
mark. I would suggest you have a look at the code for visual-line-mode
as it uses line-move-visual - essentially, setting it to t locally in
the buffer when you turn the mode on. If it was nil before starting
visual-line-mode, it sets it back to nil when you turn off the mode. So,
it seems that visual-line-mode uses line-move-visual to alter the next
line/previous line definitions when in visual line mode.

I still don't understand the question you referred to when you wrote

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

Perhaps I don't understand what you mean by logical line mode. My
interpretation was that logical line mode referred to what some would
call the 'traditional' default mode that emacs had until v23 i.e. C-n and Cp
moved to the next and previous lines where a line would be defined by
standard eol characters. If you had line wrap on for a long line that
filled 10 visual lines in your window, a single C-n would move down to
the 11th visual line i.e. C-n moves to next logical line. In visual line
mode or with line-move-visual enabled, C-n would move to the second
visual screen line i.e. you would have to do multiple C-n to get past
the 'logical line'.

For convenience of argument, since visual line mode uses
line-move-visual, lets just call it visual line mode. Noting that I
expect all the possible problems that line-move-visual would cause with
macros will also exist if you are using visual line mode as they both
redefine the movement semantics in the same way. 

From this perspective, for me, the semantics of the movement keys are
what determine which mode you are operating in. It makes no sense to ask
if C-n should move by logical lines or visual lines in logical line mode
because moving by logical lines is what defines logical line mode. If
you move by visual lines, your not in logical line mode, your in visual
line mode (using the term mode in its general sense, not its emacs
sense).

So, I still don't understand your question and I suspect I'm not alone.
This could explain the lack of response to your question and provides an
alternative to your rather negative and somewhat arrogant assertion
regarding an 'ill informed gallery'. A failure to illicit a response to
a question can easily be due to the way it is presented and does not in
itself tell you anything about the audience. 

To again make my position clear. I believe that setting line-move-visual
to t by default was a mistake. I believe the introduction of the ability
to change the semantics of line movement is a good addition, despite some
of the negative consequences and the fact that I think there is still
some work to be done to handle things like macros in a reliable
consistent manner. This ability to change the movement semantics has
enabled improved support for a number of activities, many of which have
been mentioned elsewhere in this thread. I agree that its introduction
does come with some pain, but I think its worth it. From a theoretical
basis, I can see where some of the concerns are coming from, but I've
yet to hear of an actual example where the change has caused the
cataclysmic disasters that have been predicted. I think despite some
valid points, things have been over stated. 

Which brings me to my final issue and the one that actually dragged me
into this thread. The arrogance, derogatory comments about the emacs
maintainers, sweeping generalizations and assumptions regarding
everything from their personal motivations, experience, egos and even
age has been quite outrageous. Arrogant claims of teaching them lessons
and demands for more accountability etc have been over the top and all
of this due essentially to one poor decision to change the default
behavior. There has been no recognition for all the recent improvements
in font handling, support for GTK, dbus, etc, X window support
enhancements, emacsclient improvements, improved and extended support
for different character encodings, support for larger buffers and much
more. I'm quite amazed at the development and improvements we have been
seeing. Remember how slow it was to go from emacs 20 to 21? Remember the
constant frustrations of an emacs that frequently ran into limitations
that other systems didn't experience? I think the work that has been
done over the last few years has been quite remarkable.

>
> I hope you understand the issue better now.  If you still think this is an
> acceptable change, let us know.

I understood it before, thank you master! I hope you now understand my
position better!

Tim

-- 
tcross (at) rapttech dot com dot au