emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: please make line-move-visual nil


From: Stephen J. Turnbull
Subject: Re: please make line-move-visual nil
Date: Fri, 15 May 2009 13:22:02 +0900

I think a better approach to context-dependent behavior would be
buffer-local.  Buffers where long lines are very common, and modes
where newline is paragraph end, etc, should set line-move-visual on.
Programming modes, table modes, etc should not.

Lennart Borgman writes:
 > On Thu, May 14, 2009 at 11:37 AM, Antoine Levitt <address@hidden> wrote:
 > > I think line-move-visual is great for common usage. It seems to me the
 > > problem of users with this new setting is mainly in keyboard macros. Why 
 > > not
 > > disable line-move-visual when typing or replaying a keyboard macro, since 
 > > in
 > > most case the user want the action to be independent of the line it is on ?
 > > Kind of a hack, but there's clearly two usages of the line move commands
 > > here.
 > 
 > I have also suggested turning off line-move-visual when handling
 > macros. I can't see any reason not to do that.

The whole point of a macro is "what you did is what you get", but now
people have to think about how behavior is going to change from when
they just did to when they create the macro.  That's going to reduce
the utility of macros.

One of the things that makes Emacs the great (and unusual) environment
that it is is this *deliberate* blurring of the lines between UI and
API, and between API and implementation.  Because of the rigid nature
of APIs, this necessarily causes a certain amount of rigidity in both
UI and implementation.

I don't think it's a good idea to draw a line between the UI and the
API that way.  Instead, say "I'm sorry, oldtimer, but this *is* a much
better default behavior for most users most of the time, and if it
bothers your ancient macros, switch it off."  The rigidity is not a
good thing, but please don't undermine the basic greatness of Emacs
because you dislike it.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]