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

[Juri Linkov]

> IMO marking commands are at at different level than commands that operate
> on marked files; we don't need to mimic such feature of the `dired-mark'.
> Indeed, if the user want to operate on all files, she can easily do
> `dired-mark' followed by the command in question;  I tend to think calling
> `dired-do...' things without marked files from the top line as an user 
> mistake.

Since `dired-mark' from the top line followed by the command in question
is not obvious for users, we could provide a hint in the error message,
i.e. mention the availability of ‘m’ on the top line with such message:
“You can type `m' here to mark all files for this operation”.

>>> 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.
>>
>> I agree that it's better to check the ‘files’ returned from
>> ‘dired-get-marked-files’.
>
> Today I took a deeper look in the train and I saw there are several more
> commands that don't protect against X.  Some even breaks
> (e.g., dired-do-shell-command, dired-do-async-shell-command).
>
> Below patch introduce a macro to systematically handle the 'X condition',
> what do you think?

I agree with Drew that better to use existing functions, and not to
duplicate them.  Non sunt multiplicanda entia sine necessitate.

Moreover, we should not change the old semantic of Dired commands:
if users have a habit of operating on the first files by going to the top
line and typing e.g. ‘M-< C-5 M’ to change modes of the first 5 files,
this is just fine, we should not prohobit this behaviour now.

So what we need to do is just check if the list of files returned from
‘dired-get-marked-files’ is nil, and show some message in this case in
all places that you found where the prompt with [0 files] makes no sense.