[Top][All Lists]

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

RE: please make line-move-visual nil

From: Drew Adams
Subject: RE: please make line-move-visual nil
Date: Mon, 25 May 2009 01:17:54 -0700

> > I'm coming back to this thread because I just tried the new pretest
> > (, where the default value of `line-move-visual' is t.
> > This is insane, IMO. The default value is t even in formatted modes
> > such as Buffer Menu and Info. It is t even in code modes such as
> > Emacs-Lisp. If you use `define-derived-mode' to define a 
> new mode from
> > scratch - a mode that has no parent mode, it has value t in that
> > mode. It has value t everywhere, by default.  This makes no sense.
> > If you absolutely feel the need to make the default value be t for
> > modes such as text-mode, which (you are convinced) are likely to
> > benefit from it, then do so.  But PLEASE leave the rest of Emacs
> > alone, by default. This is a bad choice for Emacs - please
> > reconsider this.
> We've talked it over repeatedly.

Well, I haven't. This is the first I've spoken up on it. Call me a latecomer.
Are you saying the party is over? Doesn't sound like it...

> Add (setq line-move-visual nil) to
> your .emacs and live happily ever after.

Right. Same old same old...

What is wrong with the proposal that the default be different, depending on the
type of buffer? That seems quite sensible.

We can argue over which buffer types should have a non-nil default, but at least
making some such division makes sense. I personally would argue that only a
minority of modes should have non-nil by default, but at least such a partition
could be discussed.

I would be perfectly happy with a non-nil default for text-mode and modes that
inherit from it or are similar to it - mail composition buffers, for instance.
And nil for the other modes - those that are for code or tabular or otherwise
formatted text (in the sense of laid out, not in the sense of enriched text).

That is a sensible default behavior, to me. I probably wouldn't even customize
it, if the defaults were like that. I don't particularly _want_ a nil value
everywhere. And I certainly don't want a non-nil value everywhere. Why not make
this a little more flexible, and give it reasonable defaults based on the buffer

reply via email to

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