bug#48883: [External] : bug#48883: dired marking bugs

[Drew Adams]

I'll chime in here, unsolicited - feel free to ignore.

Glad you reported this, Boruch.  Congratulations on
finding a decades-old problem!

> I'm coming across the following bugs
> reproducable in \emacs -Q -nw:
> 
> 1) Improper marking of directory heading line
> 
>    1.1) The correct and expected behavior of dired is that when one
>         navigates to a directory heading line (eg. the first line of a
>         simple dired buffer) and presses 'm', all "real" files of that
>         directory are marked, [IMPORTANT] the lines for the "not-real"
>         files '.' and '..' are not marked, and [IMPORTANT] the directory
>         line itself is not marked.
> 
>    1.2) Likewise, typing 'u' on that line unmarks all said lines.

(You don't say so, but I think/hope you agree that
1.1 and 1.2 are OK, not something improper.)

>    1.3) Now, advance one line, to the line typically presenting a
>         summary, beginning with the word 'total', and press the sequence
>         'C-u -1 m'.
> 
>    1.4) Why is there now a mark on the prior line, the directory line?
>         Note that the result differs from actually performing 'm' on
>         that line also in that none of the "real" files in the directory
>         are marked. Note also that performing 'u' on the line does not
>         remove the mark, but performing 'U' on the buffer does.

Agreed - a bug.

This change to `dired-repeat-over-lines' seems to
take care of that OK:

In the second `while' (the one for negative movement),
change (save-excursion (funcall function)) to this:
(when (dired-get-filename nil t) ; <=======
  (save-excursion (funcall function)))

[I've added `dired-repeat-over-lines' to dired+.el and
made that change.  If this gets fixed in vanilla Dired
too (hopefully) then I'll be able to remove that
dired+.el change - except for older Emacs versions.] 

>    1.5) Attempting to perform an operation on the marked directory line
>         (eg. 'C' to copy it) returns the message "No files specified"

IMO, that's not a problem.  (I assume here you're
talking about point being on the dir heading line
and no (other) files being marked.)  There _are_
(should be) no files specified.

> 2) Improper marking of "not-real" files '.' and '..'
> 
>    2.1) See paragraph 1.1.
> 
>    2.2) However, those lines can be manually marked using the 'm'
>         command, and attempting to perform an operation on them (eg. 'C'
>         to copy them) returns messaging indicating a willingness to
>         overwrite whatever target directory is chosen. I haven't risked
>         let it operate.
> 
>    2.3) As in paragraph 1.3, it is possible to mark the two lines using
>         a negative prefix argument.

IMO, there's nothing wrong with marking `.' or `..',
and nothing wrong with Dired having some operations
that work on them.

It's fine for it to have some other operations that
don't work for them, of course.  In that case, users
can be informed about that when they try those ops.

> 3) Improper advancing to (point-max)
> 
>    3.1) Marking the final entry in a dired buffer advances POINT to a
>         blank line, which is pretty much never desirable to a user.

I don't see that as a problem.  FWIW, with my code
(`dired+.el') a user can optionally wrap around from
the last line to the first, and vice versa, using the
line motion commands (e.g. `SPC', `down').