RE: please make line-move-visual nil

[Drew Adams]

> > 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.
> 
> You didn't give any reason to support your view.

I did too, though perhaps not explicitly enough.

Most buffers in Emacs are code buffers or formatted text, with non-proportional
fonts and hard-returns (newlines) as line separators. For _at least_ those
contexts, we should keep the normal behavior. The traditional line movement fits
well with lines as they are defined in those contexts. Lines defined by newlines
fit well with newline-oriented movement.

If a poll indicates that most people want to use the new behavior for buffers
such as text-mode, then the default can be non-nil for such buffers. I don't
have a problem with that. But my crystal ball says that those buffers are in the
minority, in Emacs.

And even if they were in the majority, it wouldn't make sense to impose non-nil
for the other buffers, which have newline-delineated lines and provide a good
fit for the traditional line movement.

This is a widespread change, and it should not be. Impose the change, if you
must impose it, on only text-oriented buffers - the kind of buffers for which
you might use a proportional font, for instance. (Yes, the two things are
different, but the use cases overlap considerably.)

Use it for mail messages and text-mode. Do not use it, by default, for code and
formatted buffers, whose content is split into newline-delineated lines by
design.

> I can see where you're coming from, though.

Even though you didn't notice the reasons I gave? ;-) Good. Maybe you sense the
reasons yourself?

> I believe line-move-visual should be t because in this mode of  
> operation, cursor movement commands correspond most closely to the  
> visual representation of the buffer.

Visual representation is not all that is important in a buffer. In code and
formatted (e.g. tabular) text, the positions of hard newlines can make a
difference.

Look, GNU Emacs Dev itself demands that Emacs-Lisp code you submit not have
lines longer than N columns. Why? Why do we format Info and *Help* and *Man* and
*Dired* buffers? Shouldn't you be proposing that we do away with all that, and
just have lines that are a zillion chars long? Let the display take care of it
all, right?

That's a different discussion, perhaps, but I sense that the door is being
opened here...

> Note that I have bound C-n/p to non-visual movement in Aquamacs,
> while arrow keys are visual.

Why would you even want non-visual movement? ;-) What's the use case/reason? Let
me guess... code? formatted buffers? most Emacs buffers?

> How about a newbie-mode, which can be en/disabled directly from the  
> startup screen?

I don't think this is about newbies at all (except that some Emacs developers
might be hoping that many newbies will be likely to use mainly Emacs for text,
mail, etc.).

I think it is about different line movements being appropriate for different
kinds of "line". The solution, in terms of finding good default behavior, is to
do this based on the buffer, that is, on its mode.

Use newline-oriented line movement for buffers where "lines" are typically
delineated by newlines. Use, if you like, visual-line-oriented movement for
buffers where "lines" have no use for newlines.

When I write a paragraph in this mail client (Outlook), there is no auto-fill or
anything that chops the text by inserting newlines. Visual line movement might
be appropriate here (and that's in fact the line movement I have).

When you read this plain-text mail, it will have had newlines inserted (for
better or, more likely, for worse), and newline-oriented line movement might be
appropriate. If I instead sent the mail as HTML, then visual line movement might
be appropriate.

> Ps.: I think it's too late in the game for 23.1 for this sort 
> of change.

Dunno if it's too late, but if time is really an argument here, then we can
argue that this change of default came too late. But I think it doesn't really
matter when we have the discussion. ;-)