RE: please make line-move-visual nil

["Drew Adams" <drew.adams@oracle.com>]

> > 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.
> 
> Much of my stuff is actually done in variable-width fonts (LaTeX  
> editing, for instance).

Sure, I can see that. Sometimes (or some parts of) LaTeX, HTML, and XML,
depending on the code. Yes. (Troff, probably not. ;-))

> Using fixed-width fonts even for code is not a must

No one said it is a must. This is about finding appropriate default values. It's
not about forcing someone to use one or the other behavior. 

The point is that it makes sense for the defaults to be different, depending on
the buffer type. Then users should be able to (easily) customize the values for
different buffer types.

> >> 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 know fairly well by now how a lot of the developers (and 
> certainly a share of the users) work.  And as RMS pointed out in a 
> related thread some time ago, much of the GNU tool set is based
> on line-by-line processing.

Yessir.

> > Why would you even want non-visual movement? ;-) What's the 
> > use case/reason? Let me guess... code? formatted buffers?
> > most Emacs buffers?
> 
> Yes, code and formatted buffers.  But even there I wouldn't want it  
> all the time - just in some situations.

Precisely. It all depends. On the buffer type. On personal preference. On the
moon, perhaps. Customization is there for personal preference, but it needs to
be easily tweakable for different contexts, as you point out. One size here does
not necessarily fit all contexts.

The _default_ behaviors should at least be tailored to a reasonable consensus
according to the buffer type. I suspect there might be consensus for a nil
default for code buffers. But that doesn't that mean some people won't want
non-nil there too, just as some people (as you suggested) might prefer
proportional fonts for code too.

> I believe that Auto-fill is a thing of the past.  The new 
> word-wrap is the way to go for non-code. Here's why:
> 
> > When you read this plain-text mail, it will have had newlines  
> > inserted (for better or, more likely, for worse),
> 
> For worse, because the text only occupies 50% of the window I use to  
> display your message.

Yes, for worse, I already agreed. But that's what happens with plain-text mail,
isn't it?

Many of us use HTML mail outside of mailing lists. But I can tell you that I
sometimes wish I had a line-oriented mode for dealing more easily with blocks of
code or tabular text in HTML emails. The most I can do using Outlook is switch
to a fixed-width font. (Yes, I know, Emacs as mail client...)