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 06:10:38 +0100 Message-ID: <87lg3foqwh.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> NNTP-Posting-Host: ciao.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ciao.gmane.org 1547961094 52614 195.159.176.228 (20 Jan 2019 05:11:34 GMT) X-Complaints-To: usenet@ciao.gmane.org NNTP-Posting-Date: Sun, 20 Jan 2019 05:11:34 +0000 (UTC) User-Agent: mu4e 1.1.0; emacs 27.0.50 Cc: emacs-devel@gnu.org, Juri Linkov To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 20 06:11:32 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 1gl5OK-000Dfq-9v for ged-emacs-devel@m.gmane.org; Sun, 20 Jan 2019 06:11:28 +0100 Original-Received: from localhost ([127.0.0.1]:35520 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gl5OT-00079U-5m for ged-emacs-devel@m.gmane.org; Sun, 20 Jan 2019 00:11:37 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50394) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gl5ON-00079N-Ly for emacs-devel@gnu.org; Sun, 20 Jan 2019 00:11:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gl5OM-0001xg-J8 for emacs-devel@gnu.org; Sun, 20 Jan 2019 00:11:31 -0500 Original-Received: from mail.mojserwer.eu ([195.110.48.8]:37556) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gl5OK-0001vP-T8; Sun, 20 Jan 2019 00:11:29 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by mail.mojserwer.eu (Postfix) with ESMTP id 1B616E673F; Sun, 20 Jan 2019 06:11:25 +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 3KIN8kubj2gi; Sun, 20 Jan 2019 06:11:20 +0100 (CET) Original-Received: from localhost (static-dwadziewiec-jedenpiec7.echostar.pl [109.232.29.157]) by mail.mojserwer.eu (Postfix) with ESMTPSA id 730BCE64BC; Sun, 20 Jan 2019 06:11:20 +0100 (CET) In-reply-to: <83a7jwatez.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:232525 Archived-At: On 2019-01-20, at 04:40, Eli Zaretskii wrote: >> From: Juri Linkov >> Date: Sat, 19 Jan 2019 23:19:19 +0200 >> Cc: Eli Zaretskii , emacs-devel@gnu.org >> >> >> Is something wrong with customizing async-shell-command-display-buffer? >> >> I have it set to nil for quite some time. >> > >> > Would it help for this use-case? That is, make the output buffers >> > disappear (even in the presence of some output), but not if a prefix >> > argument is used? >> >> Does C-u already mean inserting the output in the current buffer? >> Maybe then you could use e.g. M-0 prefix arg? > > We already have async-shell-command-display-buffer, which can be > customized to makes the buffer appear only if it has something in it. > Why is that not enough? Is the case where the user decides up front > she doesn't want to see the buffer, ever, no matter what's in it, an > important enough use case? And if it is, why a new value of > async-shell-command-display-buffer couldn't cater even to that weird > use case? Well, if `async-shell-command-display-buffer' were extended to allow that, it would obviously be enough. I'm astonished, however, that you consider this a `weird use-case'. I didn't even bother to explain it, since it seems so natural for me. Basically, I would consider it like functions. Many commands run through M-! or M-& are like "pure functions" - you are basically interested in their output. Think `ls' or `git status' or `date'. (These are not great examples, since Emacs has superior replacements for them, but take `vagrant global-status' for instance.) 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.) Now, M-& can be easily configured to fit one or the other, but not both. Does it make sense? -- Marcin Borkowski http://mbork.pl