From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Marcin Borkowski Newsgroups: gmane.emacs.devel Subject: Re: async-shell-command and prefix argument Date: Sun, 20 Jan 2019 21:26:41 +0100 Message-ID: <878szfnkhq.fsf@mbork.pl> 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> <835zujbanu.fsf@gnu.org> NNTP-Posting-Host: ciao.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ciao.gmane.org 1548016092 139115 195.159.176.228 (20 Jan 2019 20:28:12 GMT) X-Complaints-To: usenet@ciao.gmane.org NNTP-Posting-Date: Sun, 20 Jan 2019 20:28:12 +0000 (UTC) User-Agent: mu4e 1.1.0; emacs 27.0.50 Cc: emacs-devel@gnu.org, juri@linkov.net To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 20 21:28:09 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 1glJhQ-000a5p-QG for ged-emacs-devel@m.gmane.org; Sun, 20 Jan 2019 21:28:08 +0100 Original-Received: from localhost ([127.0.0.1]:43997 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glJhZ-0004Gs-KA for ged-emacs-devel@m.gmane.org; Sun, 20 Jan 2019 15:28:17 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:34080) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glJgx-0004GW-4e for emacs-devel@gnu.org; Sun, 20 Jan 2019 15:27:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1glJgw-0006YZ-1c for emacs-devel@gnu.org; Sun, 20 Jan 2019 15:27:39 -0500 Original-Received: from mail.mojserwer.eu ([195.110.48.8]:55614) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glJgu-0006Nf-6P; Sun, 20 Jan 2019 15:27:36 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by mail.mojserwer.eu (Postfix) with ESMTP id 7D369E6BE2; Sun, 20 Jan 2019 21:27:23 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.mojserwer.eu Original-Received: from mail.mojserwer.eu ([127.0.0.1]) by localhost (mail.mojserwer.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf81j8uXNrku; Sun, 20 Jan 2019 21:27:19 +0100 (CET) Original-Received: from localhost (static-dwadziewiec-jedenpiec7.echostar.pl [109.232.29.157]) by mail.mojserwer.eu (Postfix) with ESMTPSA id E4693E6650; Sun, 20 Jan 2019 21:27:18 +0100 (CET) In-reply-to: <835zujbanu.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.110.48.8 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:232555 Archived-At: On 2019-01-20, at 16:39, Eli Zaretskii wrote: >> 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". Well, you are right - in theory. Practice is different. Here are some examples. 1. Opening a png file in Gimp with xdg-open --8<---------------cut here---------------start------------->8--- $ xdg-open redacted.png (gimp-2.10:29264): Gtk-WARNING **: 21:13:40.274: Unable to locate theme engine in module_path: "adwaita", (gimp-2.10:29264): Gtk-WARNING **: 21:13:40.277: Unable to locate theme engine in module_path: "adwaita", (file-png:29282): Gtk-WARNING **: 21:13:42.558: Unable to locate theme engine in module_path: "adwaita", (file-png:29282): Gtk-WARNING **: 21:13:42.562: Unable to locate theme engine in module_path: "adwaita", --8<---------------cut here---------------end--------------->8--- I know it worked because I can see a Gimp window/frame open. 2. Running (pdf)latex on a known and tested file (so no need for diagnostics), only to produce the pdf. I know it worked because I can see (and view) the pdf. (Besides, I know the file compiles correctly anyway, I just happened to delete the pdf and I want to recreate it.) 3. Unpacking an archive with (more or less) known contents. --8<---------------cut here---------------start------------->8--- $ aunpack zzz.zip Archive: zzz.zip extracting: Unpack-6002/aaa extracting: Unpack-6002/bbb extracting: Unpack-6002/ccc zzz.zip: extracted to `zzz' (multiple files in root) --8<---------------cut here---------------end--------------->8--- I know it worked because I press `g' in Dired and I can see the results of the unpacking. 4. Viewing a pdf without the synctex file in evince. --8<---------------cut here---------------start------------->8--- $ evince mgr.pdf ! SyncTeX Error : No file? --8<---------------cut here---------------end--------------->8--- >> Does it make sense? > > Not really, sorry. Is it better now? It is all about flexibility. The author may have thought that the output is important. As a user, knowing my situation, I know that it is not important /for me/. (And I take the risk of a possible but unlikely situation of something going wrong and me not noticing, like having a full disk.) I could say ">/dev/null 2>&1" to achieve what I want. It's just that C-u is much more convenient. Best, -- Marcin Borkowski http://mbork.pl