bug#3438: please make line-move-visual nil

bug#3438: please make line-move-visual nil

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

> Please see bug report #3438. All of it is worth reading in this regard.
>
> Note in particular his request to have a buffer-local value for
> line-move-visual, and to have Dired use nil for this.

>> In dired mode, when the cursor is near the beginning of a very long
>> filename (as in near the "AaAaAa..." below , I can't move down to the
>> next file by "n" or "cursor down" key anymore(!).

In Dired, <up> and <down> call dired-previous-line and dired-next-line,
which should not be affected by line-move-visual.  I have not been able
to reproduce the reported problem (i.e., getting point stuck in Dired).
Maybe the reporter has some unusual customizations that are getting in
the way.

bug#3438: please make line-move-visual nil

[Drew Adams]

> > Please see bug report #3438. All of it is worth reading in 
> > this regard. Note in particular his request to have a
> > buffer-local value for line-move-visual, and to have Dired
> > use nil for this.
> 
> >> In dired mode, when the cursor is near the beginning of a very long
> >> filename (as in near the "AaAaAa..." below , I can't move 
> >> down to the next file by "n" or "cursor down" key anymore(!).
> 
> In Dired, <up> and <down> call dired-previous-line and 
> dired-next-line, which should not be affected by line-move-visual.
> I have not been able to reproduce the reported problem (i.e.,
> getting point stuck in Dired). Maybe the reporter has some unusual
> customizations that are getting in the way.

Ah, you're right. And I even remember that I started to mention Dired as an
example of a formatted buffer in my original post in this thread, and removed it
when I realized this was in fact the case (I used Info and Buffer List as
examples). But I forgot about it when I saw the bug report. Thx.

Dired is an exception in this regard among formatted buffers, so you are correct
that Dired's bindings make it irrelevant for the immediate question.

It does illustrate the general idea, however: line movement in formatted buffers
is often different (should often be different) than it is in free-form text
buffers. In Dired, it is particularly different, since we want point to stay on
the file name - we constrain it to one column for vertical movement.

IOW, Dired has its own buffer-local behavior for line movement, which is even
more reflective of the buffer formatting than usual. If anything, this
strengthens the argument for buffer-specific line movement, rather than
weakening it.

More typically (in formatted buffers), we want to reflect the use of newlines
(they are positioned intentionally) and maintain the current column for line
movement, but there is no single, privileged column (e.g. file name) that we
want to constrain point to, as there is in Dired.

Each formatted buffer could individually define its own line-movement commands,
which amounts to just binding `line-move-visual' to nil around a call to
`next-line'. But that would be a bit silly. Better to just let the variable be
buffer-local. And provide nil as the default value for most formatted buffers.

--

BTW, you didn't answer the questions about the poll. How's it coming along?
Where is it?

bug#3438: please make line-move-visual nil

[Stefan Monnier]

> More typically (in formatted buffers), we want to reflect the use of newlines
> (they are positioned intentionally) and maintain the current column for line
> movement, but there is no single, privileged column (e.g. file name) that we
> want to constrain point to, as there is in Dired.

I don't know if it's typical, but for most of those kinds of buffers you
describe as "formatted", I think they should at least set truncate-lines.

> Each formatted buffer could individually define its own line-movement
> commands, which amounts to just binding `line-move-visual' to nil
> around a call to `next-line'.  But that would be a bit silly.
> Better to just let the variable be buffer-local.  And provide nil as
> the default value for most formatted buffers.

Any major mode is free to (set (make-local-variable 'line-move-visual) nil).
As of now, I don't think any mode bothers to do that.

> BTW, you didn't answer the questions about the poll.
> How's it coming along?  Where is it?

I can't think of any poll which would bring any satisfactory answer to
the discussion.


        Stefan

bug#3438: please make line-move-visual nil

[Drew Adams]

> > More typically (in formatted buffers), we want to reflect 
> > the use of newlines (they are positioned intentionally)
> > and maintain the current column for line movement, but
> > there is no single, privileged column (e.g. file name)
> > that we want to constrain point to, as there is in Dired.
> 
> I don't know if it's typical, but for most of those kinds of 
> buffers you describe as "formatted", I think they should at
> least set truncate-lines.

No reason given. Why?

Why should Buffer List or Info or Man output or grep output or C code or Java
code buffers have `truncate-lines' turned on? Because newlines are intentionally
positioned in such modes, they should use `truncate-lines'? Why would that be?

Is this a diversion to some other topic? What's the relation to the topic at
hand, which is `line-move-visual'?

> > Each formatted buffer could individually define its own 
> > line-movement commands, which amounts to just binding
> > `line-move-visual' to nil around a call to `next-line'.
> > But that would be a bit silly. Better to just let the
> > variable be buffer-local.  And provide nil as
> > the default value for most formatted buffers.
> 
> Any major mode is free to (set (make-local-variable 
> 'line-move-visual) nil).

For those modes that come with Emacs, it is the Emacs code that would need to do
that. It doesn't happen by spontaneous combustion.

I proposed making the variable always buffer-local. If you don't want to do
that, then yes, each mode for which nil is appropriate would need to do that.

Or the opposite: Switch the default to nil, and let the (relatively fewer?)
modes that use primarily free-form text do (set (make-local-variable
'line-move-visual) t).

> As of now, I don't think any mode bothers to do that.

Of course not. Nothing has been done yet about this issue. That's what the
discussion is about: tailoring `line-move-visual' so that it DTRT.

Which means turn itself off, by default, for non free-text modes, that is, code
modes and modes with formatted text. IMHO.

> > BTW, you didn't answer the questions about the poll.
> > How's it coming along?  Where is it?
> 
> I can't think of any poll which would bring any satisfactory answer to
> the discussion.

"Let them eat cake!"

(Or as the right-wing French government official said back in the day, speaking
of the Nouvelle Caledonian independentistes, "Ever since we stopped listening to
them, we don't hear anything from them anymore.") Poll, what poll?

bug#3438: please make line-move-visual nil

[Lennart Borgman]

On Mon, Jun 1, 2009 at 11:00 PM, Drew Adams <drew.adams@oracle.com> wrote:
>
> I proposed making the variable always buffer-local. If you don't want to do
> that, then yes, each mode for which nil is appropriate would need to do that.

I think this is a global feature. Making it buffer local by default is
probably not the best then. It would be on the same level as makeing
the binding of C-n/C-p buffer local by default.

bug#3438: please make line-move-visual nil

[Drew Adams]

> > I proposed making the variable always buffer-local. If you 
> > don't want to do that, then yes, each mode for which nil
> > is appropriate would need to do that.
> 
> I think this is a global feature. Making it buffer local by default is
> probably not the best then.

Why? No reason given.

But you say "then", as if being a global variable is a reason it shouldn't have
a buffer-local value.

> It would be on the same level as makeing
> the binding of C-n/C-p buffer local by default.

Since we have apparently replaced the classic behavior of `next-line', so it
respects `line-move-visual', yes. (But I personally have no problem if we go
back to the classic behavior, with normal line movement in all buffers.)

If a non-nil value of `line-move-visual' is not appropriate for some (most?)
buffers, but (some people think) it is appropriate for some other buffers, then
that's the obvious conclusion: make it buffer-local.

bug#3438: please make line-move-visual nil

[Lennart Borgman]

On Mon, Jun 1, 2009 at 11:33 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> > I proposed making the variable always buffer-local. If you
>> > don't want to do that, then yes, each mode for which nil
>> > is appropriate would need to do that.
>>
>> I think this is a global feature. Making it buffer local by default is
>> probably not the best then.
>
> Why? No reason given.

Yes, I think so. In the next sentence. It is a behaviour that is
expected to be the same in most buffers for at least most new users.
It is on the same level as a key binding.

bug#3438: please make line-move-visual nil

[Stefan Monnier]

>> I don't know if it's typical, but for most of those kinds of 
>> buffers you describe as "formatted", I think they should at
>> least set truncate-lines.

> No reason given. Why?

> Why should Buffer List or Info or Man output or grep output or C code
> or Java code buffers have `truncate-lines' turned on? Because newlines
> are intentionally positioned in such modes, they should use
> `truncate-lines'? Why would that be?

Just goes to show that I misunderstood your notion of "formatted".
I was thinking of buffers like pcl-cvs, VC, dired, buffer-list, ibuffer,
... Not info, not man, not Java, not C (not sure about grep, I like to
set it in grep, but I'm not sure if it's a good idea in general).

> Is this a diversion to some other topic? What's the relation to the
> topic at hand, which is `line-move-visual'?

When truncate-lines is non-nil, visual lines and logical lines coincide,
so line-move-visual doesn't make much difference any more (other than
for proportional text, that is).

> I proposed making the variable always buffer-local.

There would be no benefit to it:
  (set (make-local-variable <foo>) <bar>)
is the standard way for major modes to set variables.


        Stefan

bug#3438: please make line-move-visual nil

[Drew Adams]

> Just goes to show that I misunderstood your notion of "formatted".
> I was thinking of buffers like pcl-cvs, VC, dired, buffer-list,
> ibuffer, ... Not info, not man, not Java, not C (not sure about
> grep, I like to set it in grep, but I'm not sure if it's a good
> idea in general).

I mentioned Info and Buffer List from the beginning. And I mentioned code
buffers and buffers with tabular formatting as well.

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.

Even for Buffer List, Dired, and the rest you mentioned, do you really "think
they should at least set `truncate-lines'? Is that slated for Emacs 23.2?

> > Is this a diversion to some other topic? What's the relation to the
> > topic at hand, which is `line-move-visual'?
> 
> When truncate-lines is non-nil, visual lines and logical 
> lines coincide, so line-move-visual doesn't make much
> difference any more (other than for proportional text, that is).

True, when the line is not wrapped in any way, there is no line-wrapping. Guess
that's one way to skirt the issue. ;-) The relation to this issue is that with
`truncate-lines' the issue is evacuated and the distinction no longer matters?

"We're trying to decide whether to order fish or meat for the group."
"Just don't eat, then it doesn't matter."

> > I proposed making the variable always buffer-local.
> 
> There would be no benefit to it:
>   (set (make-local-variable <foo>) <bar>)
> is the standard way for major modes to set variables.

I have no problem with _how_ the buffer-local value is set, as long as the
default value set for buffers that are not mostly free-form text is nil.

And I have no problem with it not being buffer-local at all, if the default
value is nil.

bug#3438: please make line-move-visual nil

[Lennart Borgman]

On Tue, Jun 2, 2009 at 12:52 AM, Drew Adams <drew.adams@oracle.com> wrote:
>
> 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 ...)

bug#3438: please make line-move-visual nil

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: "'Chong Yidong'" <cyd@stupidchicken.com>,
>         "'T.V. Raman'" <tv.raman.tv@gmail.com>, <ams@gnu.org>, <eliz@gnu.org>,
>         <stephen@xemacs.org>,
>         "'Andrew W. Nosenko'" <andrew.w.nosenko@gmail.com>,
>         <emacs-devel@gnu.org>, "'ishikawa'" <chiaki.ishikawa@ubin.jp>,
>         <3438@emacsbugs.donarmstrong.com>
> Date: Mon, 1 Jun 2009 15:52:34 -0700
> 
> I mentioned Info and Buffer List from the beginning. And I mentioned code
> buffers and buffers with tabular formatting as well.
> 
> 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.

Emacs does not reformat text in Info buffers, except for the header
lines and the "bread-crumbs" lines.  The rest is shown as produced by
makeinfo from the Texinfo sources.

bug#3438: please make line-move-visual nil

[Drew Adams]

> Emacs does not reformat text in Info buffers, except for the header
> lines and the "bread-crumbs" lines.  The rest is shown as produced by
> makeinfo from the Texinfo sources.

Info presents the _user_ with buffers formatted that way.

How Info does that - whether the info.el code does that or makeinfo does it or
Texinfo does it or the input to Texinfo is preformatted that way - is irrelevant
here.

It's about the _user_.

bug#3438: please make line-move-visual nil

[Drew Adams]

> > 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.

bug#3438: please make line-move-visual nil

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <monnier@iro.umontreal.ca>, <cyd@stupidchicken.com>,
>         <tv.raman.tv@gmail.com>, <ams@gnu.org>, <stephen@xemacs.org>,
>         <andrew.w.nosenko@gmail.com>, <emacs-devel@gnu.org>,
>         <chiaki.ishikawa@ubin.jp>, <3438@emacsbugs.donarmstrong.com>
> Date: Mon, 1 Jun 2009 16:23:50 -0700
> 
> > Emacs does not reformat text in Info buffers, except for the header
> > lines and the "bread-crumbs" lines.  The rest is shown as produced by
> > makeinfo from the Texinfo sources.
> 
> Info presents the _user_ with buffers formatted that way.

No, it does not.  It presents the text exactly as it is on disk, as if
it were a simple text file (well, almost; see above).  There's no
formatting anywhere.

We are probably miscommunicating, because I don't imagine you really
believe that Info buffers are formatted in any way.  They are free
text.

bug#3438: please make line-move-visual nil

[Drew Adams]

> > I proposed making the variable always buffer-local.

SM> There would be no benefit to it:
SM>   (set (make-local-variable <foo>) <bar>)
SM> is the standard way for major modes to set variables.

Irrelevant. This is not about how to set the variable, but whether the variable
should always be buffer-local.

`truncate-lines', `word-wrap', and similar variables are all always
buffer-local.  `line-move-visual' should be also, for the same reasons.

bug#3438: please make line-move-visual nil

[Stefan Monnier]

> `truncate-lines', `word-wrap', and similar variables are all always
> buffer-local.

`truncate-lines' is always buffer-local. for historical reasons.
`word-wrap' is buffer-local by mistake.


        Stefan

bug#3438: please make line-move-visual nil

[Drew Adams]

> > > > I proposed making the variable always buffer-local.
> > 
> > SM> There would be no benefit to it:
> > SM> (set (make-local-variable <foo>) <bar>)
> > SM> is the standard way for major modes to set variables.
> > 
> > Irrelevant. This is not about how to set the variable, but 
> > whether the variable should always be buffer-local.
> >
> > `truncate-lines', `word-wrap', and similar variables are
> > all always buffer-local.
> 
> `truncate-lines' is always buffer-local. for historical reasons.
> `word-wrap' is buffer-local by mistake.

Why do you consider the latter a mistake? Is the former a mistake too, but won't
be fixed? Why not, if it's misguided?

And `goal-column', `fill-column, `fill-prefix', `left-margin', `comment-column',
`tab-width', `require-final-newline'? Are they also mistakes?

Put it another way: Which variables that have to do with wrapping, filling,
truncating, target columns, and line/buffer endings are *NOT* always
buffer-local? Which are not mistakes?

And what's the _reason_ you call them mistakes? It's easy to dismiss -
"historical", "mistake" - but why shouldn't they be always buffer-local? What
are the criteria for your judgment?

The only reason you gave was that major modes can make variables buffer local if
they need to. That's doesn't speak to why they would or would not do that.

And if that were the answer, then we would not have _any_ variables that are
always buffer-local - we would just leave it up to major modes to make them
buffer-local as needed. Why don't we expect `comment-column' (for instance) to
simply be made buffer-local by each major mode that needs that?