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: Drew Adams
Subject: RE: please make line-move-visual nil
Date: Mon, 1 Jun 2009 16:57:56 -0700

> > The distinction I made is between buffers that are mostly 
> > free-form text, where newlines are typically not
> > intentionally positioned by the user or by Emacs, and
> > the other buffers, where they are.
> 
> Is not that a difficult distinction here? (In a word processor it
> would be different.) Exactly how do you do the distinction - as simple
> as possible, because if it is useful it must be easy to understand?
> 
> One point I mentioned before is that code might look scrambled, but
> maybe that point could be cured some way? (If it really have to be
> cured ...)

The exact decision for any given mode is not the issue.
Please don't make the perfect into the enemy of the good.

Adjustments can always be made later, based on user feedback wrt particular
modes. The important thing is to decide that non-nil `line-move-visual' should
be reserved, by default, for buffers that mostly have free-form text. That
includes text-mode, mail message buffers, and the like.

Don't search for the gray areas as a means to ignore or avoid a useful general
distinction.

Info is such a gray area. Should Info eventually become unformatted? Sure,
maybe, because most of it is just text. Things can evolve. But today, Info's
visual lines end with newlines. It has menus and headers that end in newlines.
It has code samples. But yes, most of it is just text, for which line endings
are, a priori, meaningless. I wouldn't argue much either way, for Info. Another
gray area is *Help*, for similar reasons.

But even if we disagree about how to treat Info or *Help* today, that's not the
point. To "get" the distinction, look at the extremes, not the middle: Buffer
List vs a text paragraph like this one. Think <pre> in HTML vs <p> (no, it's not
exactly the same thing, but that might help you see the distinction).

Is there a gradient from hot to cold? Of course. But not all meals are best hot,
nor all best cold. You like to eat fried chicken cold, and I like it hot. So
what? Does that mean we must pick one, hot or cold, to apply to all food?

There's individual preference, sure, and users can define buffer-local variables
as they see fit individually. But if we're serving meals for the group then we
need to decide, based on some general rules of thumb. Salad is by default cold;
soup is by default hot.





reply via email to

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