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: Tue, 19 Apr 2016 22:30:37 +0200 Message-ID: <87mvopqr2q.fsf@mbork.pl> References: <87a8kuugyb.fsf@mbork.pl> <87k2jubsih.fsf@mbork.pl> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1461097873 16983 80.91.229.3 (19 Apr 2016 20:31:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Apr 2016 20:31:13 +0000 (UTC) Cc: emacs-devel To: John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 19 22:31:05 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 1ascIZ-0001z0-10 for ged-emacs-devel@m.gmane.org; Tue, 19 Apr 2016 22:31:03 +0200 Original-Received: from localhost ([::1]:36105 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ascIY-0003MW-8Q for ged-emacs-devel@m.gmane.org; Tue, 19 Apr 2016 16:31:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49928) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ascII-00039F-Qx for emacs-devel@gnu.org; Tue, 19 Apr 2016 16:30:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ascIF-0000aH-LV for emacs-devel@gnu.org; Tue, 19 Apr 2016 16:30:46 -0400 Original-Received: from mail.mojserwer.eu ([2a01:5e00:2:52::8]:48506) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ascIF-0000Zn-FI for emacs-devel@gnu.org; Tue, 19 Apr 2016 16:30:43 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.mojserwer.eu (Postfix) with ESMTP id 6F471AE0838; Tue, 19 Apr 2016 22:30:40 +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 IUzrAO818a-Q; Tue, 19 Apr 2016 22:30:38 +0200 (CEST) Original-Received: from localhost (98-171.echostar.pl [213.156.98.171]) by mail.mojserwer.eu (Postfix) with ESMTPSA id D3763AE0836; Tue, 19 Apr 2016 22:30:37 +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:203102 Archived-At: On 2016-04-19, at 00:47, John Wiegley wrote: >>>>>> Marcin Borkowski writes: > >> That sounds interesting. What if the command ends with "!" alone? Should it >> be synchronous and silent? (I guess not.) > > That doesn't seem to make a lot of sense, does it... Well, it would follow the Unix tradition: do what should be done, say nothing;-). But joking aside, I agree. >> 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? > > I'm not sure about changing these functions in core Emacs. I can think of > still other behaviors (like not showing the async output buffer until there is > output to display). Rather than changing these venerable commands, it might be > better to explore the UI possibilities in an add-on (using advice, maybe?) for > the time being. > > Or maybe the concept the "execute but hide the buffer" should just be a new > command, provided by an ELPA package that offers more options related to > executing shell commands from the minibuffer? OK. I'm not sure whether I agree (probably not), but I solved the problem in my init.el anyway;-). I'll think about both options (I would prefer the first one, configurable with an option). >> 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. > > Yes, it should definitely be documented. So I'll start with reaping this low-hanging fruit;-). Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University