Re: line-move-visual

[Alan Mackenzie <acm@muc.de>]

In comp.emacs Mark Crispin <mrc@panda.com> wrote:
> On Sat, 12 Jun 2010, Wojciech Meyer posted:
>> Well it is certainly possible, one can use mailing list and the NEWS
>> file, which was suggested before.

> Please read the first chapter of the Hitchhiker's Guide to the Galaxy to 
> understand the flaw in that reasoning.

Please feel free to suggest a way the development team could have
canvassed users, particularly the vast majority who don't keep up with
project mailing lists.  It seems like a difficult problem.

> Apparently not, if the "customers" are told that it's their fault for
> not being on the development list.

It seems like a difficult problem.

>> What kind of Emacs users are they? Isn't possible to place on every
>> machine a stub containing: (setq line-move-visual nil).

> There include people who never use emacs, except to follow the procedure 
> that I outline (which is literally a cookbook "do these steps exactly"). 
> I have no control or access to the machines in question.

> Perhaps I should have written a program to begin with.  But it was so much 
> simpler to leverage upon emacs back in the days when emacs had a reliable 
> interface.  Now that it no longer does, I'm now forced to write the 
> program.

It seems you're exaggerating your predicament ever so slightly.  I'd
guess you could code up the replacement program (in elisp?  in sed?  in
whatever?) in less time than you've spent discussing the problem here.

It's far from obvious that this change (line-visual-mode being set) is a
Bad Thing.  Without it, moving around things like log files with 300
character lines was an utter pain.  I'd suggest it was more of a pain
than the one you're suffering, because it hit users using Emacs in its
principal way of working, rather than in special cases in some obscure feature
(keyboard macros).

since Emacs 23, I haven't felt any need whatsoever to restore l-v-m to nil,
and I haven't seen anybody else asking for it.

>> There is nothing wrong in being young and creative, that makes often
>> things better. Young people often do care more about things then
>> Senior Architects, they are also more flexible for changes.

> Yes, but they lack the wisdom and experience of their elders.  This in
> turn leads them to address complex problems with simple solutions that
> backfire (sometimes disastrously).

Hence the best team for writing something contains both
stuck-in-the-groove maturity and feckless youth.  Not that the Emacs team
is lacking in solid wisdom.

>> The reason why this setting wasn't kept by default is to fix the
>> fundamental problem,

> Yeah, right.  The "fundamental problem" that CTRL/A, CTRL/E, CTRL/N, 
> CTRL/P, etc. moved to predictable places in the file no matter what the 
> screen width, and thus could be relied upon for a cookbook procedure.

Now you've got to take screen width into account.  Big deal.

And it was dashed near impossible to move easily to the middle of long,
long lines.  I suspect this need to be commoner than using keyboard
macros on long lines.

> We can't have predictability and reliability.  We have to do
> pretty-pretty  to be just like Word, and destroy the one attribute that
> made emacs  superior to other choices.

You're exaggerating at least a little bit here.  There are lots and lots
of attributes that make Emacs superior, some of them in contention with
some others.  You could easily enough amend your instructions, prefixing
them with "M-: (setq visual-line-mode nil)".  Or you could rewrite the
thing (what does it do, exactly?) in elisp or whatever.

> Bletch.

> This wouldn't have been a problem had the arrow keys been changed to
> the new semantics and CTRL-A/E/N/P been left alone.  The new semantics
> are even arguably right for arrow keys (although I would go further and
> say that they should also treat tabs as the equivalent number of
> spaces).  It isn't as if we're still in the 1970s and have keyboards
> without arrow keys.

The arrow keys are a long way away from the home position on the
keyboard.  You're surely not suggesting rebinding those four key
sequences to something else?

> -- Mark --

-- 
Alan Mackenzie (Nuremberg, Germany).