GNU bug report logs - #3438
emacs 23.0.9{,3,4} dired mode bug(?)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 3438 in the body.
You can then email your comments to 3438 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: ishikawa <chiaki.ishikawa <at> ubin.jp>
To: emacs-pretest-bug <at> gnu.org
Cc: ISHIKAWA Chiaki <chiaki.ishikawa <at> ubin.jp>
Subject: emacs 23.0.9{,3,4} dired mode bug(?)
Date: Mon, 01 Jun 2009 16:36:52 +0900

Hi,

Thank you for making the great package available for pre-release testing.

While I began experimenting with this alpha/beta version,
I noticed a couple of lisp .elc files were not
correctly read, but I fixed them by
byte-recompile-directory.

After a day's use, I found a deeper problem with "dired" mode.

So I am reporting it here.

It is both in 23.0.93 which I initially tried, and
23.0.94 (confirmed today).

TIA.

========================================
A dired mode bug?
----------------------------------------
emacs-version : "23.0.93.1"
emacs-version : "23.0.94.1"  Both versions suffer from the same problem.


UNEXPECTED SYMPTOM:

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(!).

(Note that the folding of the long file name on the screen is such
that the said filename line is folded onto the next line. See
below. The space above the next filename "addition" is empty when
viewd with an X terminal of 100 characters wide.  Even if the width is
smaller (say, 80 chars) and "...ccccc" near the end comes above the
next file name "addition", the symptom is the same.).

Excerpt from a dired mode buffer: I am now on the line with "AaAaAa..." file.
Then I can't move the cursor down.

(darn. My current mailer refuses to send out the
lines unmodified...) Please not that the
AaAaAa... line below ought to follow 15:48 on the preceding line,
bbb... line ought to follow 15:49 on the preceding line, etc.
I hope you get the idea, though.)


  ....
  drwxr-xr-x  2 ishikawa   ishikawa  4096 2009-06-01 16:05 .
  drwxrwxrwx 62 cidellnote ishikawa 20480 2009-06-01 16:05 ..
  -rw-r--r--  1 ishikawa   ishikawa     5 2009-06-01 15:48
AaAaAaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccccccccccccccccc
  -rw-r--r--  1 ishikawa   ishikawa     9 2009-06-01 16:04 addition
  -rw-r--r--  1 ishikawa   ishikawa     4 2009-06-01 15:49
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
  -rw-r--r--  1 ishikawa   ishikawa     4 2009-06-01 15:49
cccccccccccccccccccccccccccccccccccccccccccccc
  ....



EXPECTED BEHAVIOR:

I should be able to move down to the next filename line by
the cursor/mark by "n", "cursor down", or C-n.


ADDITIONAL NOTE:

I found that to my surprise that if my cursor is at the end of "AaAaAa"
that is the 6th character position, "n" or "cursor down" key moves the
cursor (mark) to the first "A" of the filename!

As I noted once I get there, cursor can't be moved down by "n" or "cursor
down" key (or control-n for that matter) any more.

I can move to the next line with "addition" filename, by going to the
end of the long filename by "C-e" and then further does the "c-f" to
the beginning of the next line (-rw-r--r--), but this is not what
dired designer had in mind, I think.

Going upward from the file name "addtion" in the above example
works fine as expected.

COMMENT/SUGGESTIONS:

Now, I suspect that this is due to the following change quoted from
etc/NEWS.

>* Editing Changes in Emacs 23.1
>
>+++
>** The C-n and C-p line-motion commands now move by screen lines,
>taking continued lines and variable-width characters into account.
>Setting `line-move-visual' to nil reverts this to the previous
>behavior (motion by logical lines based on buffer contents alone).

But if so, I think dired-mode should make a buffer-local version of
this variable (local to dired buffer) and set it to nil, IMHO.

This is because the way the cursor is supposed to move in dired
mode. The default cursor movement behavior of dired mode in 23.0.94
is broken, IMHO.

For the testing, I simply set this variable using
M-M-: (setq line-move-visual nil) [RETURN]

As I half expected, I found that the change of the variable restores
the expected behavior.  But this again changes the behavior everywhere
which I think the developers of 23.x version didn't intend. (Or
otherwise, the default C-N behavior would not be that of the 23.0.94).
Oh well.

[end of memo]

Message #10 received at 3438 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: "'T.V. Raman'" <tv.raman.tv <at> gmail.com>,
        "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>, <ams <at> gnu.org>,
        <eliz <at> gnu.org>, <stephen <at> xemacs.org>,
        "'Andrew W. Nosenko'" <andrew.w.nosenko <at> gmail.com>,
        <emacs-devel <at> gnu.org>, "'ishikawa'" <chiaki.ishikawa <at> ubin.jp>,
        3438 <at> debbugs.gnu.org
Subject: Re: please make line-move-visual nil
Date: Mon, 01 Jun 2009 13:56:27 -0400

"Drew Adams" <drew.adams <at> 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.

Message #15 received at 3438 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> stupidchicken.com>
Cc: "'T.V. Raman'" <tv.raman.tv <at> gmail.com>,
        "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>, <ams <at> gnu.org>,
        <eliz <at> gnu.org>, <stephen <at> xemacs.org>,
        "'Andrew W. Nosenko'" <andrew.w.nosenko <at> gmail.com>,
        <emacs-devel <at> gnu.org>, "'ishikawa'" <chiaki.ishikawa <at> ubin.jp>,
        <3438 <at> debbugs.gnu.org>
Subject: RE: please make line-move-visual nil
Date: Mon, 1 Jun 2009 11:26:58 -0700

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

Message #20 received at 3438 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: "'Chong Yidong'" <cyd <at> stupidchicken.com>,
        "'T.V. Raman'" <tv.raman.tv <at> gmail.com>, <ams <at> gnu.org>, <eliz <at> gnu.org>,
        <stephen <at> xemacs.org>,
        "'Andrew W. Nosenko'" <andrew.w.nosenko <at> gmail.com>,
        <emacs-devel <at> gnu.org>, "'ishikawa'" <chiaki.ishikawa <at> ubin.jp>,
        <3438 <at> debbugs.gnu.org>
Subject: Re: please make line-move-visual nil
Date: Mon, 01 Jun 2009 16:11:49 -0400

> 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

Message #25 received at 3438 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: "'Chong Yidong'" <cyd <at> stupidchicken.com>,
        "'T.V. Raman'" <tv.raman.tv <at> gmail.com>, <ams <at> gnu.org>, <eliz <at> gnu.org>,
        <stephen <at> xemacs.org>,
        "'Andrew W. Nosenko'" <andrew.w.nosenko <at> gmail.com>,
        <emacs-devel <at> gnu.org>, "'ishikawa'" <chiaki.ishikawa <at> ubin.jp>,
        <3438 <at> debbugs.gnu.org>
Subject: RE: please make line-move-visual nil
Date: Mon, 1 Jun 2009 14:00:34 -0700

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

Message #30 received at 3438 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 3438 <at> debbugs.gnu.org,
        "T.V. Raman" <tv.raman.tv <at> gmail.com>,
        Chong Yidong <cyd <at> stupidchicken.com>,
        "Andrew W. Nosenko" <andrew.w.nosenko <at> gmail.com>, emacs-devel <at> gnu.org,
        ishikawa <chiaki.ishikawa <at> ubin.jp>, ams <at> gnu.org, stephen <at> xemacs.org,
        eliz <at> gnu.org
Subject: Re: please make line-move-visual nil
Date: Mon, 1 Jun 2009 23:25:40 +0200

On Mon, Jun 1, 2009 at 11:00 PM, Drew Adams <drew.adams <at> 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.

Message #35 received at 3438 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Lennart Borgman'" <lennart.borgman <at> gmail.com>
Cc: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>,
        <3438 <at> debbugs.gnu.org>,
        "'T.V. Raman'" <tv.raman.tv <at> gmail.com>,
        "'Chong Yidong'" <cyd <at> stupidchicken.com>,
        "'Andrew W. Nosenko'" <andrew.w.nosenko <at> gmail.com>,
        <emacs-devel <at> gnu.org>, "'ishikawa'" <chiaki.ishikawa <at> ubin.jp>,
        <ams <at> gnu.org>, <stephen <at> xemacs.org>, <eliz <at> gnu.org>
Subject: RE: please make line-move-visual nil
Date: Mon, 1 Jun 2009 14:33:54 -0700

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

Message #40 received at 3438 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 3438 <at> debbugs.gnu.org,
        "T.V. Raman" <tv.raman.tv <at> gmail.com>,
        Chong Yidong <cyd <at> stupidchicken.com>,
        "Andrew W. Nosenko" <andrew.w.nosenko <at> gmail.com>, emacs-devel <at> gnu.org,
        ishikawa <chiaki.ishikawa <at> ubin.jp>, ams <at> gnu.org, stephen <at> xemacs.org,
        eliz <at> gnu.org
Subject: Re: please make line-move-visual nil
Date: Mon, 1 Jun 2009 23:56:13 +0200

On Mon, Jun 1, 2009 at 11:33 PM, Drew Adams <drew.adams <at> 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.

Message #45 received at 3438 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: "'Chong Yidong'" <cyd <at> stupidchicken.com>,
        "'T.V. Raman'" <tv.raman.tv <at> gmail.com>, <ams <at> gnu.org>, <eliz <at> gnu.org>,
        <stephen <at> xemacs.org>,
        "'Andrew W. Nosenko'" <andrew.w.nosenko <at> gmail.com>,
        <emacs-devel <at> gnu.org>, "'ishikawa'" <chiaki.ishikawa <at> ubin.jp>,
        <3438 <at> debbugs.gnu.org>
Subject: Re: please make line-move-visual nil
Date: Mon, 01 Jun 2009 18:33:33 -0400

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

Message #50 received at 3438 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: "'Chong Yidong'" <cyd <at> stupidchicken.com>,
        "'T.V. Raman'" <tv.raman.tv <at> gmail.com>, <ams <at> gnu.org>, <eliz <at> gnu.org>,
        <stephen <at> xemacs.org>,
        "'Andrew W. Nosenko'" <andrew.w.nosenko <at> gmail.com>,
        <emacs-devel <at> gnu.org>, "'ishikawa'" <chiaki.ishikawa <at> ubin.jp>,
        <3438 <at> debbugs.gnu.org>
Subject: RE: please make line-move-visual nil
Date: Mon, 1 Jun 2009 15:52:34 -0700

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

Message #55 received at 3438 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 3438 <at> debbugs.gnu.org,
        "T.V. Raman" <tv.raman.tv <at> gmail.com>,
        Chong Yidong <cyd <at> stupidchicken.com>,
        "Andrew W. Nosenko" <andrew.w.nosenko <at> gmail.com>, emacs-devel <at> gnu.org,
        ishikawa <chiaki.ishikawa <at> ubin.jp>, ams <at> gnu.org, stephen <at> xemacs.org,
        eliz <at> gnu.org
Subject: Re: please make line-move-visual nil
Date: Tue, 2 Jun 2009 01:12:57 +0200

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

Message #60 received at 3438 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: monnier <at> iro.umontreal.ca, cyd <at> stupidchicken.com, tv.raman.tv <at> gmail.com,
        ams <at> gnu.org, stephen <at> xemacs.org, andrew.w.nosenko <at> gmail.com,
        emacs-devel <at> gnu.org, chiaki.ishikawa <at> ubin.jp,
        3438 <at> debbugs.gnu.org
Subject: Re: please make line-move-visual nil
Date: Mon, 01 Jun 2009 19:13:41 -0400

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: "'Chong Yidong'" <cyd <at> stupidchicken.com>,
>         "'T.V. Raman'" <tv.raman.tv <at> gmail.com>, <ams <at> gnu.org>, <eliz <at> gnu.org>,
>         <stephen <at> xemacs.org>,
>         "'Andrew W. Nosenko'" <andrew.w.nosenko <at> gmail.com>,
>         <emacs-devel <at> gnu.org>, "'ishikawa'" <chiaki.ishikawa <at> ubin.jp>,
>         <3438 <at> 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.

Message #65 received at 3438 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: <monnier <at> iro.umontreal.ca>, <cyd <at> stupidchicken.com>,
        <tv.raman.tv <at> gmail.com>, <ams <at> gnu.org>, <stephen <at> xemacs.org>,
        <andrew.w.nosenko <at> gmail.com>, <emacs-devel <at> gnu.org>,
        <chiaki.ishikawa <at> ubin.jp>, <3438 <at> debbugs.gnu.org>
Subject: RE: please make line-move-visual nil
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.

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

Message #70 received at 3438 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Lennart Borgman'" <lennart.borgman <at> gmail.com>
Cc: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>,
        <3438 <at> debbugs.gnu.org>,
        "'T.V. Raman'" <tv.raman.tv <at> gmail.com>,
        "'Chong Yidong'" <cyd <at> stupidchicken.com>,
        "'Andrew W. Nosenko'" <andrew.w.nosenko <at> gmail.com>,
        <emacs-devel <at> gnu.org>, "'ishikawa'" <chiaki.ishikawa <at> ubin.jp>,
        <ams <at> gnu.org>, <stephen <at> xemacs.org>, <eliz <at> gnu.org>
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.

Message #75 received at 3438 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: ishikawa <chiaki.ishikawa <at> ubin.jp>
To: 3438 <at> debbugs.gnu.org
Subject: It was a configuration problem (re: (emacs 23.0.9{,3,4} dired mode
 bug(?)))
Date: Tue, 02 Jun 2009 15:29:31 +0900

I am the original reporter.

Sorry that my innocuous post caused a discussion of die-hard
differences of preferences, it seems.
(It has been going on and off since the late 80's if I recall correctly.)

After a false startup, I finally narrow down the problem to
my hastily configured testing environment.

Indeed, when I ran emacs -q that said misbehavior is no longer
observed.
(as noted by  Chong Yidong <cyd <at> stupidchicken.com>
in message #10 in the bug database readable from the web interface.
Since I am not on the mailing list, I can only read the follow-ups
using this web interface. And thus my followup is delayed. Sorry for
the delay.
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3438


BAD environment.:

In my .emacs file, I explicitly set the load-path to those of GNU
emacs 22.2 lisp directory.  (I was using Debian GNU/linux and usually
I obtain the emacs tar ball myself and install it disregarding the
ordinary package supplied by debian.)  Because of the explicit setup,
23.0.94 read the older dired.el of 22.2 distribution.

When I fixed the configuration so that emacs startup reads
the files under the latest lisp directory, all is well now.

(I sometimes wonder how the beta and alpha testers set up their .emacs
files.)

Here is the sleuth work I did.

===================
1. In dired mode, "n", C-n, and  cursor down key are bound to dired-next-line

(From C-h k n in dired mode buffer)

n runs the command dired-next-line, which is an interactive compiled Lisp
function in `dired.el'.
It is bound to <down>, n, SPC, C-n.
(dired-next-line ARG)

Move down lines then position at filename.
Optional prefix ARG says how many lines to move; default is one line.

[back]

======================
2. Let me take a look at dired-next-line. This is in dired.el

23.0.94
(defun dired-next-line (arg)
  "Move down lines then position at filename.
Optional prefix ARG says how many lines to move; default is one line."
  (interactive "p")
  (forward-line arg)
  (dired-move-to-filename))

These lines look fine.
Actually, I spent a couple of hours looking inside the latest lisp files
and manually invoking forward-line, et al from console using "M-X"
even redefining dired-move-to-filename to be interactive so that
I can invoke it by "M-X". But then all was well.

When I realized the clean startup (-q) works OK from the earlier post, I
realized that my .emacs seems to be preferring lisp files under 22.2
lisp directory. So  I looked at the old dired.el under 22.2

GNU Emacs 22.2.

(defun dired-next-line (arg)
  "Move down lines then position at filename.
Optional prefix ARG says how many lines to move; default is one line."
  (interactive "p")
  (next-line arg)      <===== AHA, CULPRIT!
  (dired-move-to-filename))


In 22.2, next-line is called instead of forward-line.
This explains the misbehavior, and the cure caused by
(setq line-move-visual nil).

Now, I modified my .emacs file so that
load-path contains the latest test emacs lisp directory
at the beginning when I invoke 23.0.9x beta/alpha.
And all is well.

Thank you again for taking the time to look at my now false-positive
bug report.


BTW, as I mentioned at the beginning, the pros and cons of various
settings have been rehashed over the years (a couple of decades at
least).

All I can suggest is to leave enough hooks (to the point that the
unsuspecting user can hang himself/herself if careless) so that the
user can customize the environment.

In hindsight, though, there are good customization paths that prove to
be easy to incorporate future changes and difficult to work with
later, but again these are hindsight and I have no good guideline to
offer. I am afraid only a close brush with the difficulty and ease
of customization and then upgrade can give people the "feel" for the
design.

As a side note, I have so many customizations done over the
years (I consolidated emacs setup files in 1991 which I had used in
the late 1980's on various machines, Sun, HP, DEC, etc. and under
different OS versions, and still use the remnant today), and
some customizations are now difficult to deal with and sometimes I
have no idea what some lisp code snipets do despite my efforts to
comment them, but fearing interrupted
behavior, I have left them in in for now (for the last several years).

(cf. I even have a temporary fix for broken ld/dump for an arcane system.
  in one of the customization files emacs reads.
  ;;;
  ;;; fix for buggy C compilation, linking, or dumping.
  ;;; text-char-description is broken. (This was on SunOS 3? or 4? on Sun3
  ;;;
  (if (not (and (string-equal "x" (text-char-description ?x ))
		(string-equal "y" (text-char-description ?y ))
		(string-equal "z" (text-char-description ?z ))))
      (progn
	(message "Buggy text-char-description is overwritten.")
	(load-library "tcdfix")))
  ;;;;;;;;


Such is life.

TIA.

Message #80 received at 3438 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: monnier <at> iro.umontreal.ca, cyd <at> stupidchicken.com, tv.raman.tv <at> gmail.com,
        ams <at> gnu.org, stephen <at> xemacs.org, andrew.w.nosenko <at> gmail.com,
        emacs-devel <at> gnu.org, chiaki.ishikawa <at> ubin.jp,
        3438 <at> debbugs.gnu.org
Subject: Re: please make line-move-visual nil
Date: Tue, 02 Jun 2009 11:59:53 -0400

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <monnier <at> iro.umontreal.ca>, <cyd <at> stupidchicken.com>,
>         <tv.raman.tv <at> gmail.com>, <ams <at> gnu.org>, <stephen <at> xemacs.org>,
>         <andrew.w.nosenko <at> gmail.com>, <emacs-devel <at> gnu.org>,
>         <chiaki.ishikawa <at> ubin.jp>, <3438 <at> 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.

Message #85 received at 3438 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <emacs-devel <at> gnu.org>
Cc: <3438 <at> debbugs.gnu.org>
Subject: RE: please make line-move-visual nil
Date: Fri, 12 Jun 2009 10:16:57 -0700

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

Message #90 received at 3438 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: <emacs-devel <at> gnu.org>, 3438 <at> debbugs.gnu.org
Subject: Re: please make line-move-visual nil
Date: Fri, 12 Jun 2009 17:45:40 -0400

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

Message #95 received at 3438 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: <emacs-devel <at> gnu.org>, <3438 <at> debbugs.gnu.org>
Subject: RE: please make line-move-visual nil
Date: Fri, 12 Jun 2009 17:19:27 -0700

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

Message #100 received at 3438-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm+emacsbugs <at> gnu.org>
To: 3438-done <at> debbugs.gnu.org
Subject: Re: It was a configuration problem (re: (emacs 23.0.9{,3,4} dired mode bug(?)))
Date: Thu, 18 Jun 2009 15:29:42 -0400

ishikawa wrote:

> After a false startup, I finally narrow down the problem to
> my hastily configured testing environment.
[...]
> In my .emacs file, I explicitly set the load-path to those of GNU
> emacs 22.2 lisp directory.


Thanks for letting us know. Closing this bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.