bug#71554: 29.3; eshell-command async buffer behavior

[Jim Porter <jporterbugs@gmail.com>]

On 7/5/2024 9:12 PM, Thierry Volpiatto wrote:
>              (cond
>               ((with-current-buffer bufname
>                  (and (null eshell-foreground-command)
>                       (null eshell-background-commands)))
>                ;; The old buffer is done executing; kill it so we can
>                ;; take its place.
>                (kill-buffer bufname))
> 
> What if user ran a serie of commands and want to see the output of each
> one?

I did that to preserve the logic of 'shell-command': if there's no 
running process in the buffer, it will get reused. That's the 
Eshell-ified analogue to this bit in 'shell-command':

	      ;; Ask the user what to do with already running process.
	      (when proc  ;; <-- This line.
		(cond
		 ((eq async-shell-command-buffer 'confirm-kill-process)
                   ...

Is that always what users want? Hard to say. Still, I think behaving 
like 'shell-command' is a good thing in order to follow the principle of 
least surprise. (If we changed the behavior in 'eshell-command', I think 
we'd want to do the same in 'shell-command' too.)

For users who *do* want something like that behavior, I think there are 
two options:

1. You could redirect the output in the Eshell command you enter at the 
prompt. For example:

   do-something &> (generate-new-buffer "mybuf") &

That would put the output from "do-something" into a unique buffer, 
running it asynchronously. (It wouldn't display the buffer by default, 
though with a bit of Elisp you could make it do that too.)

2. We could patch 'eshell-command' to be more like 'shell-command', and 
have a signature like:

   (defun eshell-command (command &optional output-buffer error-buffer)
     ...)

That way, you could output to a unique buffer (or any Eshell target, in 
fact) by passing it as an argument. I have a WIP patch to add this.