From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: async-shell-command and prefix argument Date: Sun, 20 Jan 2019 17:39:49 +0200 Message-ID: <835zujbanu.fsf@gnu.org> References: <87bm4jnevo.fsf@mbork.pl> <83zhs1ddxw.fsf@gnu.org> <871s5dt3cj.fsf@mbork.pl> <87won0fia8.fsf@mail.linkov.net> <83a7jwatez.fsf@gnu.org> <87lg3foqwh.fsf@mbork.pl> NNTP-Posting-Host: ciao.gmane.org X-Trace: ciao.gmane.org 1547998810 91722 195.159.176.228 (20 Jan 2019 15:40:10 GMT) X-Complaints-To: usenet@ciao.gmane.org NNTP-Posting-Date: Sun, 20 Jan 2019 15:40:10 +0000 (UTC) Cc: emacs-devel@gnu.org, juri@linkov.net To: Marcin Borkowski Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 20 16:40:08 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1glFCe-000Nqa-LJ for ged-emacs-devel@m.gmane.org; Sun, 20 Jan 2019 16:40:04 +0100 Original-Received: from localhost ([127.0.0.1]:41215 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glFCn-0000UU-P3 for ged-emacs-devel@m.gmane.org; Sun, 20 Jan 2019 10:40:13 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40410) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glFCh-0000Sm-8k for emacs-devel@gnu.org; Sun, 20 Jan 2019 10:40:08 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49684) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glFCg-0007Vp-Pd; Sun, 20 Jan 2019 10:40:06 -0500 Original-Received: from [176.228.60.248] (port=1446 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1glFCg-0001Uq-DI; Sun, 20 Jan 2019 10:40:06 -0500 In-reply-to: <87lg3foqwh.fsf@mbork.pl> (message from Marcin Borkowski on Sun, 20 Jan 2019 06:10:38 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:232540 Archived-At: > From: Marcin Borkowski > Cc: Juri Linkov , emacs-devel@gnu.org > Date: Sun, 20 Jan 2019 06:10:38 +0100 > > I'm astonished, however, that you consider this a `weird use-case'. It is weird because you, in effect, give up any diagnostic output from the command, such as warnings or errors, up front. Since no one can reliably predict such diagnostics, I wonder how do you even know that those commands did what you intended them to do. It's like flying blind while also turning off all the instruments. > OTOH, some external commands are there only for their side effects - > think `rm' or `aunpack or `xdg-open'. (Notice that the last two often > /have/ output, only that you may be not interested in seeing it.) Commands invoked "for side effects" will not produce any output, so setting async-shell-command-display-buffer to nil will do exactly what (I think) you want: display nothing if there's no output, and display the diagnostics otherwise. OTOH, if such a command does display something, it means the author of the command thought it was important enough to show that, even though the command is "for side effects". > Does it make sense? Not really, sorry.