GNU bug report logs -
#48072
28.0.50: dired-read-shell-command: handle empty input properly [PATCH]
Previous Next
Full log
Message #56 received at 48072 <at> debbugs.gnu.org (full text, mbox):
> 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.