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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thierry Volpiatto <thievol <at> posteo.net>
Cc: christopher <at> librehacker.com, 71554 <at> debbugs.gnu.org
Subject: Re: bug#71554: 29.3; eshell-command async buffer behavior
Date: Fri, 14 Jun 2024 21:56:50 +0300

> Cc: 71554 <at> debbugs.gnu.org
> From: Thierry Volpiatto <thievol <at> posteo.net>
> Date: Fri, 14 Jun 2024 18:53:07 +0000
> 
> Christopher Howard <christopher <at> librehacker.com> writes:
> 
> > Hello, I run a lot of async commands a lot with eshell-command,
> > preferring it over shell-command. However, there is a difference
> > between shell-command and eshell-command behavior which is a little
> > bothersome and does not make sense to me. If I run an async command
> > with shell-command, e.g. `sleep 60 &', and then run another one while
> > the first one is still running, shell-command will ask me if I want to
> > create a new buffer for the output, and I usually do. However, if I do
> > the same thing with eshell-command, eshell command will give me only
> > two options, either (1) kill the currently running command, or (2)
> > don't create an output buffer, which also throws an error. I was
> > wondering if it would be possible to add the "create a new buffer"
> > option to eshell-command as well, for the upcoming 30 release.
> 
> Please do not add a "ask to create a new buffer" option to fix this
> issue, just do not ask and create a new buffer

What if the user is not aware that a command is already running?  More
generally, why being consistent with what shell-command does is not a
good idea?

Previous Next

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