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

Previous Next

Package: emacs;

Reported by: Boruch Baum <boruch_baum <at> gmx.com>

Date: Tue, 27 Apr 2021 19:03:02 UTC

Severity: minor

Found in version 28.0.50

Full log


Message #56 received at 48072 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 48072 <at> debbugs.gnu.org, kevin.legouguec <at> gmail.com
Subject: Re: bug#48072: 28.0.50: dired-read-shell-command: handle empty input
 properly [PATCH]
Date: Wed, 28 Apr 2021 18:13:11 +0300
> Date: Wed, 28 Apr 2021 11:01:44 -0400
> From: Boruch Baum <boruch_baum <at> gmx.com>
> Cc: kevin.legouguec <at> gmail.com, 48072 <at> debbugs.gnu.org
> 
> > > > 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.
> 
> You had that idea correct in your prior paragraph, where your wrote:
> 
>    "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"

Then I already stated my opinion about this above.  I wonder what do
others think about such a feature.

> 2.1.1) Try the following in a vanilla dired buffer: Navigate POINT to a file,
>        let's say 'bar', and press '&' for the async command. Then type in some
>        garbage command, let's say 'foo', and <RET>. The response I get is a
>        message in the mini-buffer: "foo bar&wait: finished." (BTW, I haven't
>        figured out where that message is being generated; anyone's help would be
>        appreciated; I would like to see if it can report errors).

I think the message comes from process.c:status_notify, which is
called when the process is deleted after it exits.




This bug report was last modified 3 years and 331 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.