bug#30285: dired-do-chmod vs. top line of dired

[Drew Adams <drew.adams@oracle.com>]

> >> > (Why doesn't it just complain "can't operate on" like it does for
> the
> >> > third line, ".".)
> >> Following patch just do nothing in these cases.  That's OK for me.
> >> Do you prefer to inform the user in this case that there is no file
> >> to change the mode?
> >
> > Yes, I think we should produce some message in these cases.
> OK.  Then, we must adjust other siblings commands (dired-do-chgrp,
> dired-do-chown);  otherwise they might become jealous.
> I propose to add a new predicate
> `dired-marked-files-or-file-at-point-p', and used it in all those
> commands.

Please don't do any such thing.

Yes, it makes sense for such commands to do nothing or to show an
error message when on the "top line of dired", as described in the
bug report.

No, we don't need a function `dired-marked-files-or-file-at-point-p',
for that or anything else.  The `dired-do-*' commands already DTRT
wrt the marked-files-or-file-at-point.

And no, it doesn't make sense to act that way on `.' - it's OK to
change the properties of the current directory (provided you have
the necessary permissions).  And that's not even part of this bug
report, is it?

The question of `..' is arguable, but I'd say the same thing for
it as for `.': It's OK to change its properties, provided you have
permission to do so.  After all, `..' is just a (unique) directory.

How did this bug report move from being about behavior on the top
line (and the second, "total" etc. line) to being also about the
lines for `.' and `..'?