bug#48072: 28.0.50: dired-read-shell-command: handle empty input properly [PATCH]

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 28 Apr 2021 08:49:52 -0400
> From: Boruch Baum <boruch_baum@gmx.com>
> Cc: kevin.legouguec@gmail.com, 48072@debbugs.gnu.org
> 
> On 2021-04-28 14:58, Eli Zaretskii wrote:
> > > Date: Wed, 28 Apr 2021 05:50:54 -0400
> > > From: Boruch Baum <boruch_baum@gmx.com>
> > > Cc: Eli Zaretskii <eliz@gnu.org>, 48072@debbugs.gnu.org
> > >
> > > I could restrict the check to the preparation of list of completion
> > > candidates for the defaults put into the mini-buffer history (already
> > > done in diredc, as an advice around function dired-guess-default), and
> > > give dired users feedback when a command returns an error condition (on
> > > this week's plan anyway).
> >
> > I'm not sure I understand what you are suggesting.  Do you mean set up
> > the completion candidates so that they would only include executable
> > files found on the system, but allow users also to type commands that
> > are not among the completion candidates?  I think this could be
> > confusing, and I don't think we have a precedent for such a behavior
> > elsewhere.
> 
> I don't understand what your point of confusion is, but it's your call,
> of course. Your position has emacs offering users impossible choices,
> choices guaranteed to fail.

I'm asking you to help me understand the details of restricting the
check that you are proposing.  Once I understand that, I could make up
my mind about the proposal.  Right now I simply don't understand it.