GNU bug report logs - #71554
29.3; eshell-command async buffer behavior

Previous Next

Full log

Message #56 received at 71554 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Thierry Volpiatto <thievol <at> posteo.net>
Cc: christopher <at> librehacker.com, Eli Zaretskii <eliz <at> gnu.org>,
 71554 <at> debbugs.gnu.org
Subject: Re: bug#71554: 29.3; eshell-command async buffer behavior
Date: Fri, 5 Jul 2024 10:41:20 -0700

On 7/5/2024 7:34 AM, Thierry Volpiatto wrote:
> Here the patch modified (only changed default value, a typo and the
> commit message).

Thanks. One question about this before I merge: is the 'cl-loop' part 
necessary? I glossed over that part when reviewing the patch previously, 
but thinking about it more (and consulting 'shell-command' and 
'shell-command--same-buffer-confirm'), I'm not sure we need it.

My understanding is that this would prompt the user if there were a 
buffer named "*Eshell Async Command Output*" (good), but also if there 
were a buffer named "*Eshell Async Command Output*<2>" (possibly 
unnecessary). I can see the reasoning for doing this for the 
'confirm-kill-process' setting (it tries to keep the number of async 
Eshell commands to 1), but less so for the other settings. I don't think 
it's useful for 'confirm-new-buffer' or 'confirm-rename-buffer'.

Given the above, and that 'shell-command' doesn't do this, maybe Eshell 
shouldn't either?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.