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

[Eli Zaretskii]

> Date: Sat, 31 Mar 2018 09:10:41 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: juri@linkov.net, 30938@debbugs.gnu.org
> 
> > 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[p]-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).
> 
> Don't confuse a command that invokes `dired-get-marked-files'
> with a command that invokes a command that invokes
> `dired-get-marked-files'.  Their behaviors can differ (and
> in the general case they do), including wrt interactive and
> non-interactive use.

Summary: I'm not convinced.  Some details below.

> `diredp-insert-subdirs' inserts the subdir of the current
> line, if no subdirs are marked.  If none are marked and it
> is called from a non-subdir line then it _should_ raise an
> error interactively (and it does).
> 
> Should it also do so non-interactively?  Why should it
> decide that?  Why not let its caller do that?  When
> called non-interactively it cannot (and need not) know
> what is the right way to handle that case.

AFAIU, you have all the tools to make it do that, by judicious use of
the ARG and ERROR arguments.

> Imaginary command `insert-marked-subdirs-and-do-stuff'
> should _not_ raise an error, and its invocation of
> `diredp-insert-subdirs' should be a _no-op_, in the
> same situation where invoking `diredp-insert-subdirs'
> interactively would raise an error.

If diredp-insert-subdirs is designed to support that, its interface
should allow that.  Commands that aren't designed to support that have
no obligations to allow calling them like that.  IOW freedom of
applications to invoke commands and functions outside their intended
domain is not unlimited, and asking for it to be unlimited, or
insisting that the limits be made wider, no matter the costs, is IMO
unreasonable.

> Being able to do that is for the benefit of reusing a
> command that calls `dired-get-marked-files' in different
> ways.

Such reuses have their limitations.  One of them is when no files are
marked and there's no "current file".  Those commands signal an error
because they cannot fulfill their contract; silently doing nothing in
this case is against that contract.

> While it is typically a user error if nothing is marked
> and point is not on any file line, it is not necessarily
> an error when neither of those is the case - even for an
> interactive case.

Signaling an error is a widely accepted way of telling the caller "you
asked me to do something; I didn't, and here's why".  If worse comes
to worst, the caller can always catch the error and recover from it.

> To me, the solution is simple: let a command that invokes
> `d-g-m-f' pass non-nil ERROR when the command is called
> interactively.

That solution causes unreasonable complication on a dozen of commands
for no good reason, so I don't see why we should do that.