bug#13649: boobytrapped dired-do-async-shell-command question

[jid...@jidanni.org]

& runs the command dired-do-async-shell-command, which is an
interactive autoloaded compiled Lisp function in `dired-aux.el'.

It sometimes will ask
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...

So perhaps rewrite it so one knows there is only one good choice if one
wants to proceed...

[Stefan Monnier]

Maybe a better fix is to add a message afterwards, along the lines of
"Haha! Gotcha!"


Stefan

[jid...@jidanni.org]

>>>>> "SM" == Stefan Monnier <mon...@IRO.UMontreal.CA> writes:

SM> Maybe a better fix is to add a message afterwards, along the lines of
SM> "Haha! Gotcha!"

Or play them the Step Off video
http://www.youtube.com/watch?v=-_g7CZJMnJA&list=PL3A8BC534123C8364

[Juri Linkov]

> 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)

77 characters long, but I have no idea how to make it shorter
without much loss of meaning.

[Eli Zaretskii]

> From: Juri Linkov <ju...@jurta.org>
> Date: Fri, 08 Feb 2013 10:25:01 +0200
> Cc: 13...@debbugs.gnu.org

>
> > 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)

Still not clear, IMO (what "default buffer"? run what?). How about

Shell output buffer is used by another command; run this command in a new buffer (yes or no)?

> 77 characters long, but I have no idea how to make it shorter
> without much loss of meaning.

I think we should try making it crystal clear and not worry too much
about its length. The minibuffer is perfectly capable of displaying
multi-line prompts.

[Stefan Monnier]

>> 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".


Stefan

[Stefan Monnier]

> The minibuffer is perfectly capable of displaying multi-line prompts.

Not mine, because it doesn't know how to grow a minibuffer-only frame.


Stefan

[Eli Zaretskii]

> From: Stefan Monnier <mon...@iro.umontreal.ca>
> Cc: Juri Linkov <ju...@jurta.org>, 13...@debbugs.gnu.org, jid...@jidanni.org
> Date: Fri, 08 Feb 2013 11:03:23 -0500

>
> > The minibuffer is perfectly capable of displaying multi-line prompts.
>
> Not mine, because it doesn't know how to grow a minibuffer-only frame.

I doubt that your minibuffer-only frames are only 1 line high. It's
not like I suggested a 10,000-character prompt or something.

[Drew Adams]

> > The minibuffer is perfectly capable of displaying
> > multi-line prompts.
>
> Not mine, because it doesn't know how to grow a minibuffer-only frame.

I assume that your point is not to assume that users have a minibuffer that can
grow.

But just in case you are also interested in growing a standalone minibuffer, see
`1on1-fit-minibuffer' here:
http://www.emacswiki.org/emacs-en/download/oneonone.el

I add it to `post-command-hook':
(if (and 1on1-fit-minibuffer-frame-flag (require 'fit-frame nil t))
(add-hook 'post-command-hook '1on1-fit-minibuffer-frame)
(remove-hook 'post-command-hook '1on1-fit-minibuffer-frame))

[Stefan Monnier]

> I doubt that your minibuffer-only frames are only 1 line high.

And yet, they are.

> It's not like I suggested a 10,000-character prompt or something.

But indeed, they're longer than 80 columns (they're 250 columns long,
tho most of it is off the screen, actually displayed is probably closer
to 160).


Stefan

[Drew Adams]

FWIW, by default the minibuffer frame in oneonone.el is 100% of the display
width and is 2 chars high. For me, with a `frame-char-width' of 8, that's 160
chars wide.

160 * 2 = 320, which is not very different from Stefan's 250.

[Juri Linkov]

>> > 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)
>

> Still not clear, IMO (what "default buffer"? run what?). How about
>
> Shell output buffer is used by another command; run this command in a new buffer (yes or no)?

I'd rather make the prompt short and add a "help" option
(e.g. "yes/no/help" or "y/n/h") that will display the full
explanation of all options with a link to their customization.

[Juri Linkov]

>>> 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.

[Stefan Monnier]

> 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.

BTW, one more useful option would be "run it when the current command
finishes".


Stefan

[jid...@jidanni.org]

>>>>> "SM" == Stefan Monnier <mon...@iro.umontreal.ca> writes:
SM> A command is running in the default buffer. Kill it or use a new buffer?

SM> with C-g being the answer for "don't use a new buffer and don't kill it".
OK but mention that third C-g option there too.

[Eli Zaretskii]

> > Shell output buffer is used by another command; run this command in a new buffer (yes or no)?
>
> I'd rather make the prompt short and add a "help" option
> (e.g. "yes/no/help" or "y/n/h") that will display the full
> explanation of all options with a link to their customization.

That's a wrong way to treat this kind of problems, in my experience.
People need clear description of the problem because they more often
than not are nervous to be bugged with a question to begin with; the
assumption they will want to look up some help is false.

[Juri Linkov]

>> A command is running in the default buffer. What to do? (k/c/r/h)

Or rather to model the prompt after `save-some-buffers-action-alist'
that asks "Save file? (y, n, !, ., q, C-r, d or C-h)" and ask:

A command is running. Kill it? (y, n, c, r, or C-h)

where the key `y' would mean to kill the running process, `c' - create

a new buffer, `r' - rename the buffer with the running process, and

`C-h' - help with the explanation of these options including `C-g':

C-g to quit (cancel the whole command);

> BTW, one more useful option would be "run it when the current command
> finishes".

IIUC, this will require adding a queue of postponed commands, and also UI
to handle them (e.g. to remove a submitted command from the queue, etc.)

[jid...@jidanni.org]

You guys are forgetting what the user really wants in the first place.
All he wants to do is do another
$ some_command &
as in the shell.
He is used to doing lots of these without regard if the previous one has
finished yet or not... else what fun would asynchronous be?

Therefore the wisest thing would be to automatically create
*Async Output of bla gla* (or no word Async)
*Async Output of moo goo*
*Async Output of bla gla<2>*
for him, without bothering him with questions.

[Juri Linkov]

You can customize `async-shell-command-buffer' to `new-buffer'
(labeled "Create a new buffer") that creates new buffers
automatically without questions.

[jid...@jidanni.org]

JL> You can customize `async-shell-command-buffer' to `new-buffer'
Ahhh! If only I ever knew! OK.

But I see if just adds a <2>, it really should also give a hint about
what was run in the buffer name.

[Juri Linkov]

To see what was run in the buffer name is possible with `M-x list-processes'.

[jid...@jidanni.org]

>>>>> "JL" == Juri Linkov <ju...@jurta.org> writes:
JL> To see what was run in the buffer name is possible with `M-x list-processes'.
But ah ha ha ... only if the process is still running!

[Stefan Monnier]

>> BTW, one more useful option would be "run it when the current command
>> finishes".
> IIUC, this will require adding a queue of postponed commands,

You could just add-function on the process-sentinel.
But as pointed out elsewhere, another option is to actually let both
processes run in the same buffer.


Stefan

[Juri Linkov]

>>>>>> "JL" == Juri Linkov <ju...@jurta.org> writes:
> JL> To see what was run in the buffer name is possible with `M-x list-processes'.
> But ah ha ha ... only if the process is still running!

The async process buffer could have a header/footer like in compilation:

-*- mode: shell; default-directory: "~/" -*-
Async Shell Command started at Mon Feb 11 11:15:45

command line
output
output
output

Async Shell Command finished at Mon Feb 11 11:15:48