GNU bug report logs -
#71554
29.3; eshell-command async buffer behavior
Previous Next
Full log
Message #76 received at 71554 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 318 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.