Re: please make line-move-visual nil

[Alan Mackenzie <acm@muc.de>]

On Thu, May 14, 2009 at 09:20:44AM -0700, David Reitter wrote:
> On May 14, 2009, at 9:00 AM, Shaun Johnson wrote:

> >Alfred M. Szmidt wrote:
> >>Please make line-move-visual nil, it is totally uninutive to have the
> >>point move to the same line, when you explicitly told it to move to
> >>the next line.

> >FWIW I completely agree, I find this behaviour bizarre in the extreme.
> >I appreciate that others, coming from a different background, may find
> >this behaviour intuitive but I don't see that as a reason to change
> >such a core behaviour.

> For people seeking to understand the reasons behind this default  
> choice at this late stage in the release process, it may be helpful to  
> review the discussions here about the new word-wrap (soft wrapping)  
> feature, where continued buffer lines comprise whole paragraphs in  
> text rather than just the occasional over-long line in code.  Also,  
> consider the increased use of variable width fonts, which are standard  
> for non-code text in modern operating environments.

I don't see anything bizarre and extreme about this change, but as a
minor point I wish this change had been made by rebinding C-n to a [new?]
command `next-visual-line'.  It used to be that "line" meant the text
between two \n's, and now its definition has become vague and mushy.

I think I'm marginally in favour of C-n, C-p moving by screen lines,
since the pain it causes old-timers (having to type C-n again) is less
than the pain of navigating through buffers with long lines when C-n
jumps over several screen lines.  But yes, these new commands will cuase
pain for people who use them in keyboard macros.  These people will
probably twig quite quickly what's amiss, and will be able to fix it at
the cost of a throbbing headache.

> On a more general note, I wonder why experienced users occasionally
> resist change in the UI in general (as it breaks things) rather than  
> avoiding to upgrade.

[linguistic point: "avoid" takes a noun or a gerund (which needn't be
round), not an infinitive.  You want "avoiding an upgrade" or "avoiding
upgrading" here.]

You're not trying to ignite another rambling heated debate about changing
long standing features, are you?  OK, thought not.

Changing the UI makes the new version incompatible with the learning of
the users of the old versions.  Either they must relearn things, which is
painful, or they must track down the options they need to unset to make
it work how it used to, which is painful.  This pain is a Bad Thing.
Only if the new UI is stunningly good is the change justified.  IMAO, the
UI changes in Emacs 23 aren't justified.

> Perhaps, providing bug fixes for previous branches (e.g., Emacs 22) for
> a few years after the release of a new  full version would mitigate
> these issues.

It's too much work at the moment.  It might become feasible with bazaar.
That's pure speculation by the way - I haven't tried bazaar out yet.

-- 
Alan Mackenzie (Nuremberg, Germany).