GNU bug report logs -
#13649
boobytrapped dired-do-async-shell-command question
Previous Next
Reported by: jidanni <at> jidanni.org
Date: Thu, 7 Feb 2013 16:28:02 UTC
Severity: minor
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
>>> A command is running in the default buffer. Use a new buffer? (yes or no)
>>> Which is a boobytrapped question, as picking "no" will always end up
>>> in failure...
>> Ah, to you "no" means "don't use a new buffer"? Yes, this is too ambiguous.
>> A better question would be:
>
>> A command is running in the default buffer. Run in a new buffer?
>> (yes or no)
>
> I think it's got the same problem. I think the question should be more
> something like:
>
> A command is running in the default buffer. Kill it or use a new buffer?
>
> with C-g being the answer for "don't use a new buffer and don't kill it".
Alas, this means there is no more "yes/no" question. Of course,
it could be split to two "yes/no" questions like `find-alternate-file'
used to do until the recent changes that now asks only one question
(yes-or-no-p "Kill and replace the buffer without saving it? ")
I see no way to do the same for the async-shell-command default question.
There is a separate option in `async-shell-command' that asks that question
"A command is running in the default buffer. Kill it? ". If is also
possible to combine all other options into one question like:
A command is running in the default buffer. What to do? (k/c/r/h)
where the key `k' would mean to kill the running process, `c' - create
a new buffer, `r' - rename the buffer with the running process, and
`h' - help with the explanation of these options.
This bug report was last modified 3 years and 88 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.