From: Thierry Volpiatto <thievol@posteo.net>
To: Jim Porter <jporterbugs@gmail.com>
Cc: Thierry Volpiatto <thievol@posteo.net>,
christopher@librehacker.com, Eli Zaretskii <eliz@gnu.org>,
71554@debbugs.gnu.org
Subject: bug#71554: 29.3; eshell-command async buffer behavior
Date: Sat, 06 Jul 2024 06:10:42 +0000 [thread overview]
Message-ID: <87zfqvvyn1.fsf@posteo.net> (raw)
In-Reply-To: <88dd9e27-6593-db9b-2d17-cd5ae7abf547@gmail.com> (Jim Porter's message of "Fri, 5 Jul 2024 22:28:56 -0700")
[-- Attachment #1: Type: text/plain, Size: 2721 bytes --]
Jim Porter <jporterbugs@gmail.com> writes:
> 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?
I don't think so, I for one prefer keeping the buffers around to see the
output of each commands:
If I run:
com1 &
com2 &
com3 &
I expect
*buf* <=> com1
*buf<1>* <=> com2
*buf<2>* <=> com3
What if com3 overwrite *buf* where com1 exited with error, I have no
clue of what happened to com1.
I can't retrieve the initial bug report of Christopher, IIRC he was
describing his workflow running several shell commands, don't remember
if he had to examine each process buffer. Christopher?
> Hard to say. Still, I think behaving like 'shell-command' is a good
> thing in order to follow the principle of least surprise.
Yes but following exactly what 'shell-command' does prevents improving both.
> (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.
In both options, IMHO it is to much to write in addition of the shell
command itself.
--
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]
next prev parent reply other threads:[~2024-07-06 6:10 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-14 13:57 bug#71554: 29.3; eshell-command async buffer behavior Christopher Howard
2024-06-14 18:53 ` Thierry Volpiatto
2024-06-14 18:56 ` Eli Zaretskii
2024-06-14 20:32 ` Thierry Volpiatto
2024-06-14 22:49 ` Jim Porter
2024-06-15 5:13 ` Thierry Volpiatto
2024-06-20 7:30 ` Thierry Volpiatto
2024-06-24 5:36 ` Jim Porter
2024-06-24 6:23 ` Thierry Volpiatto
2024-06-24 12:33 ` Eli Zaretskii
2024-07-05 4:09 ` Thierry Volpiatto
2024-07-05 5:46 ` Eli Zaretskii
2024-07-05 6:24 ` Thierry Volpiatto
2024-07-05 11:11 ` Eli Zaretskii
2024-07-05 12:21 ` Thierry Volpiatto
2024-07-05 14:34 ` Thierry Volpiatto
2024-07-05 17:41 ` Jim Porter
2024-07-05 18:44 ` Thierry Volpiatto
2024-07-05 20:23 ` Jim Porter
2024-07-06 2:48 ` Jim Porter
2024-07-06 3:34 ` Thierry Volpiatto
2024-07-06 4:12 ` Thierry Volpiatto
2024-07-06 5:28 ` Jim Porter
2024-07-06 6:10 ` Thierry Volpiatto [this message]
2024-06-24 14:15 ` Christopher Howard
2024-07-06 15:13 ` Christopher Howard
2024-07-06 17:06 ` Thierry Volpiatto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zfqvvyn1.fsf@posteo.net \
--to=thievol@posteo.net \
--cc=71554@debbugs.gnu.org \
--cc=christopher@librehacker.com \
--cc=eliz@gnu.org \
--cc=jporterbugs@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.