From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Marcin Borkowski Newsgroups: gmane.emacs.devel Subject: Re: async-shell-command Date: Mon, 18 Apr 2016 21:56:22 +0200 Message-ID: <87k2jubsih.fsf@mbork.pl> References: <87a8kuugyb.fsf@mbork.pl> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1461009408 12944 80.91.229.3 (18 Apr 2016 19:56:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Apr 2016 19:56:48 +0000 (UTC) Cc: emacs-devel To: John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 18 21:56:42 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1asFHk-00061v-UG for ged-emacs-devel@m.gmane.org; Mon, 18 Apr 2016 21:56:41 +0200 Original-Received: from localhost ([::1]:44558 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asFHk-0005ME-9u for ged-emacs-devel@m.gmane.org; Mon, 18 Apr 2016 15:56:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54466) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asFHg-0005Jc-KO for emacs-devel@gnu.org; Mon, 18 Apr 2016 15:56:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1asFHb-0008Dz-OS for emacs-devel@gnu.org; Mon, 18 Apr 2016 15:56:36 -0400 Original-Received: from mail.mojserwer.eu ([2a01:5e00:2:52::8]:53531) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asFHb-0008Dm-H2 for emacs-devel@gnu.org; Mon, 18 Apr 2016 15:56:31 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.mojserwer.eu (Postfix) with ESMTP id 4E5DEAD8873; Mon, 18 Apr 2016 21:56:30 +0200 (CEST) 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 jh1syCBICd2E; Mon, 18 Apr 2016 21:56:27 +0200 (CEST) Original-Received: from localhost (98-171.echostar.pl [213.156.98.171]) by mail.mojserwer.eu (Postfix) with ESMTPSA id BA120AD8871; Mon, 18 Apr 2016 21:56:27 +0200 (CEST) User-agent: mu4e 0.9.13; emacs 25.1.50.8 In-reply-to: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2a01:5e00:2:52::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:203070 Archived-At: On 2016-04-16, at 20:44, John Wiegley wrote: >>>>>> Marcin Borkowski writes: > >> Of course, this is extremely hackish. I thought that stock Emacs could use >> the prefix argument to `async-shell-command' for something else than "make >> this synchronous after all, and put the result at point", which seems odd >> (and not documented, btw). For instance, C-u M-& might /not/ show the *Async >> Shell Command* buffer, and when some option is set, this hiding/showing >> behavior would be reversed (as in my solution). OTOH, maybe the current way >> of doing things is fine, and just needs mentioning in the docstring? > >> Any ideas? WDYT? > > None of the current invocation commands use a prefix argument to control > display, so this would be a departure from established practice. I think the > change you've described is better done locally, for those who want such > behavior. I expected such an answer, and I pretty much agree. I just wanted to ask whether I'm the only one who could find something like that useful (from some private email exchange I know that not), and whether the UI I proposed (C-u) makes sense (this is at least debatable). > Another way of doing this that might be nicer would be to check if the > shell-command string ends in "&!" instead of "&", and to take that as an > indication it should be executed both asynchronously and "silently" (without > display). That sounds interesting. What if the command ends with "!" alone? Should it be synchronous and silent? (I guess not.) John, would you like me to explore this idea further and try to come up with a patch? Are there any other ideas for the UI? Also, no matter how we indicate "silent" runs, what do people think about the idea of an option to /invert/ things, so that running a command /without/ the "silent" flag makes it silent (IOW, making `async-shell-command' "silent" by default)? Also, I'm pretty sure that the current meaning of the prefix argument for `async-shell-command' /must/ be documented - it is far from obvious, and can be learned only from careful reading of the code. I'm going to prepare such a patch for docs (both the docstring and the manual) first. Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University