bug#3438: emacs 23.0.9{,3,4} dired mode bug(?)

[ishikawa <chiaki.ishikawa@ubin.jp>]

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]