Starting multiple async processes from inside dired using &

Starting multiple async processes from inside dired using &

[Tassilo Horn]

Hi all,

I've just noticed that it's not possible to start multiple asynchronous
processes using `shell-command', because they all want to be associated
with the one and only "*Async Shell Command*" buffer.

This is especially annoying when using dired and its `&'
(dired-do-async-shell-command) command.  I frequently want to open a
file with an external application, and as long as this process is alive,
another & will query

  A command is running.  Kill it? (yes or no) 

where I don't want to kill the former process.  As a workaround, I can
rename the *Async Shell Command* buffer before starting the second
process, but that's quite inconvenient.

IMO, the right thing would be to create another *Async Shell Command*
buffer, uniquified with the executed command and its pid or something
like that.

Am I missing something obvious, because it looks to me like some quite
normal dired use case?

Bye,
Tassilo

Re: Starting multiple async processes from inside dired using &

[Chong Yidong]

Tassilo Horn <tassilo@member.fsf.org> writes:

> IMO, the right thing would be to create another *Async Shell Command*
> buffer, uniquified with the executed command and its pid or something
> like that.
>
> Am I missing something obvious, because it looks to me like some quite
> normal dired use case?

The only problem I can see is that these buffers will proliferate if you
execute lots of async commands over the course of a session.  So instead
of uniquifying, the code first needs to search for an *Async Shell
Command XXX* buffer containing a dead process, and only uniquify if no
such buffer exists.

Re: Starting multiple async processes from inside dired using &

[Juri Linkov]

>> IMO, the right thing would be to create another *Async Shell Command*
>> buffer, uniquified with the executed command and its pid or something
>> like that.
>>
>> Am I missing something obvious, because it looks to me like some quite
>> normal dired use case?
>
> The only problem I can see is that these buffers will proliferate if you
> execute lots of async commands over the course of a session.

Yes, this is a real problem.  I've tried for some time using a patch
that creates a new *Async Shell Command* buffer for every async process
and it ends up collecting a lot of dead *Async Shell Command*<N> buffers.

> So instead of uniquifying, the code first needs to search for an
> *Async Shell Command XXX* buffer containing a dead process, and only
> uniquify if no such buffer exists.

It seems the best option is to search and revive an existing buffer,
but there is another problem: the user might want to keep the output
of an old *Async Shell Command*<N> buffer and not overwrite it with
the output of another process.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Starting multiple async processes from inside dired using &

[Drew Adams]

> It seems the best option is to search and revive an existing buffer,
> but there is another problem: the user might want to keep the output
> of an old *Async Shell Command*<N> buffer and not overwrite it with
> the output of another process.

If only dead buffers are automatically recycled, where is the problem?

For non-dead old *Async Shell Command*<N> buffers, let the user clean house on
demand, using a command that shows the names of the buffers and lets you delete
them selectively (or all at once).

Re: Starting multiple async processes from inside dired using &

[Chong Yidong]

> For non-dead old *Async Shell Command*<N> buffers, let the user clean
> house on demand, using a command that shows the names of the buffers
> and lets you delete them selectively (or all at once).

No, that's too complicated.  This should be handled automatically.

>> It seems the best option is to search and revive an existing buffer,
>> but there is another problem: the user might want to keep the output
>> of an old *Async Shell Command*<N> buffer and not overwrite it with
>> the output of another process.

Emacs could retain the old output, concatenating the new output into it.
We do something similar for, e.g., the output of M-x byte-compile-file
in the *Compile-Log* buffer.  This should just be a matter of replacing
the `erase-buffer' call in `shell-command'.

Re: Starting multiple async processes from inside dired using &

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
>>> It seems the best option is to search and revive an existing buffer,
>>> but there is another problem: the user might want to keep the output
>>> of an old *Async Shell Command*<N> buffer and not overwrite it with
>>> the output of another process.
>
> Emacs could retain the old output, concatenating the new output into it.

That could be very confusing for someone who just wants "the output"
tho...

I think many async processes have no output tho, so maybe it's not a big
deal... (actually the "no output" thing is one reason why Emacs'
behavior WRT async process is so annoying -- Emacs seems to treat them
as if output were expected and important)

Maybe it could keep a list of previously created async output buffers,
and reuse any which are empty (and whose associated process is dead).

[E.g.:  everytime a new async process is started append its buffer to a
list.  When looking for a new async buffer, search for the first entry in
the list whose process is dead; if the buffer is empty, then reuse it,
and delete it from the list (to be added again as a new entry),
otherwise just delete it and keep searching.]

Perhaps another issue, BTW is whether Emacs should kill asynch processes
when exiting.  For the most common uses I have, it _shouldn't_, and it's
surprising and annoying when it does (I typically say "yes" to the "kill
processes?" prompt because I'm thinking of only those synchronous
processed I know about, so occasionally I end up inadvertently killing
an async process that I didn't want to...]

-Miles

-- 
My books focus on timeless truths.  -- Donald Knuth

Re: Starting multiple async processes from inside dired using &

[Juri Linkov]

>> It seems the best option is to search and revive an existing buffer,
>> but there is another problem: the user might want to keep the output
>> of an old *Async Shell Command*<N> buffer and not overwrite it with
>> the output of another process.
>
> If only dead buffers are automatically recycled, where is the problem?

Actually I meant buffers with a dead process, not simply dead buffers.

> For non-dead old *Async Shell Command*<N> buffers, let the user clean house on
> demand, using a command that shows the names of the buffers and lets you delete
> them selectively (or all at once).

Such a command to clean buffers already exists:
`M-x kill-matching-buffers RET Async Shell RET'

But it would be better to try not to create too much
garbage buffers in the first place than requiring
from the user to clean them up.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Starting multiple async processes from inside dired using &

[Juri Linkov]

>>>> It seems the best option is to search and revive an existing buffer,
>>>> but there is another problem: the user might want to keep the output
>>>> of an old *Async Shell Command*<N> buffer and not overwrite it with
>>>> the output of another process.
>>
>> Emacs could retain the old output, concatenating the new output into it.
>
> That could be very confusing for someone who just wants "the output"
> tho...

Yes, unrelated command outputs will create a mess in the same buffer.

> Maybe it could keep a list of previously created async output buffers,
> and reuse any which are empty (and whose associated process is dead).

Empty async output buffers is a small subset of use cases.
The problem of reusing command buffers is more general -
e.g. grep and compile often overwrite old output that was
necessary to keep.

> Perhaps another issue, BTW is whether Emacs should kill asynch processes
> when exiting.  For the most common uses I have, it _shouldn't_, and it's
> surprising and annoying when it does (I typically say "yes" to the "kill
> processes?" prompt because I'm thinking of only those synchronous
> processed I know about, so occasionally I end up inadvertently killing
> an async process that I didn't want to...]

Maybe asking an additional question about async processes and detaching
them when exiting will help?

-- 
Juri Linkov
http://www.jurta.org/emacs/