[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#71554: 29.3; eshell-command async buffer behavior
From: |
Thierry Volpiatto |
Subject: |
bug#71554: 29.3; eshell-command async buffer behavior |
Date: |
Sat, 06 Jul 2024 06:10:42 +0000 |
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
signature.asc
Description: PGP signature
- bug#71554: 29.3; eshell-command async buffer behavior, (continued)
- bug#71554: 29.3; eshell-command async buffer behavior, Eli Zaretskii, 2024/07/05
- bug#71554: 29.3; eshell-command async buffer behavior, Thierry Volpiatto, 2024/07/05
- bug#71554: 29.3; eshell-command async buffer behavior, Thierry Volpiatto, 2024/07/05
- bug#71554: 29.3; eshell-command async buffer behavior, Jim Porter, 2024/07/05
- bug#71554: 29.3; eshell-command async buffer behavior, Thierry Volpiatto, 2024/07/05
- bug#71554: 29.3; eshell-command async buffer behavior, Jim Porter, 2024/07/05
- bug#71554: 29.3; eshell-command async buffer behavior, Jim Porter, 2024/07/05
- bug#71554: 29.3; eshell-command async buffer behavior, Thierry Volpiatto, 2024/07/05
- bug#71554: 29.3; eshell-command async buffer behavior, Thierry Volpiatto, 2024/07/06
- bug#71554: 29.3; eshell-command async buffer behavior, Jim Porter, 2024/07/06
- bug#71554: 29.3; eshell-command async buffer behavior,
Thierry Volpiatto <=
bug#71554: 29.3; eshell-command async buffer behavior, Christopher Howard, 2024/07/06