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

[Drew Adams]

> > Emacs has already updated those 13 commands (there's one
> > also in dired-x.el) to add the 5th arg to their calls to
> > `dired-get-marked-files'.  The only further change needed
> > is to pass that arg as non-nil only when the command is
> > called interactively.  It is only in the interactive case
> > that we can know (assume) that such an error should be
> > raised.
> 
> Don't you see there is something wrong in adding the same INTERACTIVEP
> arg to all these 13 commands and possibly to more 15 other commands?
> What I'm asking for is an alternative, e.g. to detect if the command is
> called interactively and raise an error only in this case.

Instead of asking me if I don't see there is something
wrong with that, why don't you tell us what you think
is wrong with it?

I said from the beginning:

  Please revert this change as soon as possible,
  while you look for a better way to do what you
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  intended to do for it.

I'm open to other ways to do what is needed, if they
are better.  Feel free to propose something.

I'm fine with what I proposed - either proposal:

1. What I proposed at the outset: revert the bad change
   and do nothing until a better approach is decided on.

2. What I proposed in my follow-up: provide an INTERACTIVEP
   arg to distinguish interactive use, and (at most) raise
   a `user-error' only in the interactive-call case.

You asked if there was a better approach than doing #2.
I replied that #2 seems fine, to me.  But please feel free
to propose another approach, explaining why you think it's
better.

Someone apparently thought it was OK to change 13 commands
to ALWAYS raise an error in the no-files case.  Why are
you shocked to hear that I would be OK with changing those
same commands to not raise the error in the non-interactive
case - IOW, to return them to their longstanding behavior
in that case?

As for the other 15 commands: I don't know whether whoever
changed the 13 also considered the 15 and decided no error
was ever needed in their case.  But if not then the same
attention would be needed for them either to fix them as I
suggested (#2) or to break them as has been done for the
13.

I see no problem at all with having different behavior
when interactive and when not, especially when the only
difference is whether to raise an error in a corner case.

And the way to do that (explicitly recommended in the
manual) to make that distinction is to add an optional
INTERACTIVEP arg.