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

[Eli Zaretskii]

> Date: Fri, 30 Mar 2018 10:12:13 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: juri@linkov.net, 30938@debbugs.gnu.org
> 
> A non-interactive use case for an arbitrary command that
> calls ` dired-get-marked-files' does not necessarily
> have `user-error' as the right behavior for an empty set
> of marked files.  That's all I'm saying.

I'm sorry, but you lost me.  Let me try explaining this from my POV.

First, dired-get-marked-files _can_ be invoked when no files are
marked, without risking a user-error: it has the ARG argument for
that.  So if your hypothetical command needs for some reason to work
when no files are marked, it can, at least in principle.  Why your
dired-insert-subdirs didn't go that way, or at least didn't pass nil
as ERROR, I don't understand (and I'm not sure it's related to the
issue at hand).

It is true that dired-aux.el commands that call dired-get-marked-files
all pass nil as ARG (and t as ERROR), but what would be the semantics
of, say, dired-do-isearch-regexp when no files are marked?  That
command, and all the others which call dired-get-marked-files in the
same manner, is to do something on "all marked files", as their doc
string clearly says.

So why do we need to allow these commands to be invoked when no files
are marked, and expect them not to signal a user-error?

IOW, even if dired-do-isearch-regexp and its ilk are invoked
non-interactively, they are invoked as result of some command up the
call-stack, so the invocation does come from the user.  And since
dired-do-isearch-regexp etc. are documented to act on marked files, it
sounds appropriate to signal an error when no files are marked.  A
feature which wants to allow users to get away silently in this case
can always check whether any files are marked and avoid calling
dired-do-isearch-regexp etc. if none are.

That is why I asked for real-time use-cases where this gets in the
way: your argument sounds like a general philosophical issue to me:
you claim that it's "completely inappropriate" for a utility function
to signal an error on theoretical grounds, while in reality I still
don't see any practical problem that cannot be easily resolved.  If
your diredp-insert-subdirs is an example of a problem, then as I said
above, I don't understand why you couldn't just omit the last optional
argument to dired-get-marked-files, and be done.  (And since ERROR was
_added_ in Emacs 27, your original code should have been already
future-proof against such changes anyway.)