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

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

> I would like all `dired-do...' commands behave the same under the
> 'X condition': * called from the top line ** no marked files.

I've already said that it's not only about the top line.
It's about the ordinary Dired situation of not being on a
file line.  Plenty of Dired code already deals (simply)
with this "X condition".

The important things about a command that acts on the
marked files are that (1) it acts on the N next files,
if given a numeric prefix arg, (2) if no prefix arg,
it acts on the marked files, if any, (3) if not prefix
arg and no marked files it acts on the file of the
current line, and (4) it doesn't do something confusing
if there is no prefix arg, there are no marked files,
and there is no file on the current line. 

This bug is only about case (4) - a corner case.  The
solution is to just let the user know that s?he is not
on a file line.

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

Sorry, Tino, but I don't have the time or the will to
check your large patch.

My impression is that you guys are going overboard.

This bug is a _trivial_ usability bug.  There is nothing
really wrong with the existing behavior.  But yes, it
is unnecessary, and it could be slightly confusing, to
prompt the user about acting on zero files.

The trivial bug should be fixed; sure.  But it's not
a big deal.

The fix is also trivial.  Dired already provides what
is needed, as has been pointed out: just check the
return value of `dired-get-marked-files'.

If no files are marked then handle use of the command
as a `user-error': inform the user that there is no
file on the current line and no files are marked.
End of story.

This is trivial to do, and the resulting (corner case)
behavior will be simple, consistent, and clear to all
users.

If some `dired-do-*' command does not already use
`dired-get-marked-files' up front, and if it is not
appropriate for it to use it, then there are at least
two other alternatives that Dired offers to detect
this corner case.  I already mentioned them.  Using
either of them to fix the bug is also trivial.

In sum: trivial problem, trivial solution.

I'm not happy seeing big changes made to Dired code
gratuitously.  I don't have the time to argue about
it or provide alternative patches.  But I hope you
will not go down the road you seem to be going down.
Just one opinion.