bug#30938: 27.0; `dired-do-create-files' etc.: do NOT always raise error if no files

[Drew Adams]

> A lot of discussion gone under the bridge, but I asked a question in
> the very beginning that was apparently ignored:
> 
>   Please provide at least one example (preferably more than one) of a
>   real-life use case where these changes get in the way.
> 
> Without an answer to that, I cannot see why we have to do anything
> about this issue, because up front I see no problem here at all, not
> one that has been spelled out.

I answered your question, pointing to the example of calling
`dired-do-isearch' (or any of the other such commands)
non-interactively - e.g., by creating a command that uses it.

If you don't believe that a user or another library could
or would define such a command (or in any other way would
call an existing function that calls the workhorse function
`dired-get-marked-files', then too bad.

In that case your idea of real-life use of Emacs Lisp differs
from mine; you will close the bug; and we will move on.  I've
already fixed my code to work around this change (except for
`dired-do-chxxx' repercussions - see below).

---

`dired-get-marked-files' is no less a utility function than
is, say, `dired-get-filename'.  And functions, including
commands, that call it are themselves candidates for reuse
in defining other functions, including other commands.

In addition, users often look to the definitions of Emacs
commands when creating similar or derivative commands.

Imagine that a user wants a command similar to
`dired-do-search' but that does things a bit differently.
S?he might look at the def of `dired-do-isearch' for
inspiration, and thus copy its use of `dired-marked-files'.
Hard-coding a non-nil 5th arg for it is a bad model.

(Same thing for `dired-do-search' etc. and the other
commands that, for some reason (?), have not yet
undergone this change.)

---

Similarly, for `dired-do-chxxx', which is NOT a command,
and which currently hardcodes a non-nil 5th arg to
`dired-get-marked-files' just like the commands do.

To fix that aberration a bit more surgery is required,
no doubt.  We could add an optional ERROR-IF-NONE-P arg
to `dired-do-chxxx', and obtain that from an optional
INTERACTIVEP arg to `dired-do-chmod' etc.  IOW, same
kind of fix.  Or perhaps Juri has a better fix in mind.

And as for "real-life" examples, BTW, I do define
`-mouse-' versions of the `dired-do-ch*' commands.
E.g.:

(defun diredp-mouse-do-chmod (event)
  "Change the mode of this file.
This calls chmod, so symbolic modes like `g+w' are allowed."
  (interactive "e")
  (let ((mouse-pos  (event-start event)))
    (select-window (posn-window mouse-pos))
    (goto-char (posn-point mouse-pos)))
  (dired-do-chxxx "Mode" "chmod" 'chmod 1)
  (diredp-previous-line 1))

As I haven't yet bothered to fix the now-bugged
`dired-do-chxxx' locally, such "real-life" commands
of mine are still broken by this recent change (for
the moment).

You can do nothing to fix this bug, and wait to see
whether Drew is the only one who has or will ever
have code that gets bitten by it.  Or you can DTRT
and not hardcode raising an error systematically
whenever `dired-get-marked-files' would come up
with no files.