From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#18133: Suppressing asynchronous command output Date: Thu, 29 Dec 2016 17:50:06 +0200 Message-ID: <83a8bevioh.fsf@gnu.org> References: <83zijp180n.fsf@gnu.org> <83eg100vy5.fsf@gnu.org> <585C132B.1030709@gmx.at> <585C347D.9050309@gmx.at> <585D740B.40303@gmx.at> <585D8120.1090300@gmx.at> <87fula1dbk.fsf@mail.linkov.net> <83r34tx53w.fsf@gnu.org> <83eg0twwje.fsf@gnu.org> <83r34sujou.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1483026684 4859 195.159.176.226 (29 Dec 2016 15:51:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Dec 2016 15:51:24 +0000 (UTC) Cc: 18133@debbugs.gnu.org, juri@linkov.net To: Reuben Thomas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 29 16:51:20 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cMcz2-0008Ai-9v for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Dec 2016 16:51:12 +0100 Original-Received: from localhost ([::1]:36118 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMcz5-00031f-NX for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Dec 2016 10:51:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47280) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMcyw-0002zz-Pq for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2016 10:51:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cMcys-0005y7-SA for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2016 10:51:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43865) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cMcys-0005xk-O7 for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2016 10:51:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cMcys-0005Sv-Dy for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2016 10:51:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 29 Dec 2016 15:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18133 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18133-submit@debbugs.gnu.org id=B18133.148302662720951 (code B ref 18133); Thu, 29 Dec 2016 15:51:02 +0000 Original-Received: (at 18133) by debbugs.gnu.org; 29 Dec 2016 15:50:27 +0000 Original-Received: from localhost ([127.0.0.1]:59261 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cMcyF-0005Ri-42 for submit@debbugs.gnu.org; Thu, 29 Dec 2016 10:50:26 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:56136) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cMcyD-0005RU-5G for 18133@debbugs.gnu.org; Thu, 29 Dec 2016 10:50:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cMcy4-0005fQ-54 for 18133@debbugs.gnu.org; Thu, 29 Dec 2016 10:50:16 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54642) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMcy4-0005fL-1k; Thu, 29 Dec 2016 10:50:12 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1247 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cMcy2-0006eH-84; Thu, 29 Dec 2016 10:50:11 -0500 In-reply-to: (message from Reuben Thomas on Wed, 28 Dec 2016 20:58:40 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:127549 Archived-At: > From: Reuben Thomas > Date: Wed, 28 Dec 2016 20:58:40 +0000 > Cc: Juri Linkov , martin rudalics , 18133@debbugs.gnu.org > > It appears: > > . in ibuf-ext.el, as one of several strings users can select > . in tramp-adb.el as a buffer where the shell output should go > . in tramp.el, likewise > . in simple.el, likewise > . in comments in some other files > > By contrast, you were hard-coding it in a function that should provide > optional behavior for buffers that are not necessarily related to > shell output. In that context, I think the user should be able to > instruct Emacs about the buffers which should exhibit this behavior. > > ​As I said, the name is editable in M-x customize-variable.​ Yes, but AFAIU, that doesn't affect the function about which I was commenting. > > You can tick/untick the option for "*Async Shell Command*", and, when it is ticked, the regexp can be > edited. > > But if I select that, what I get is that the buffer will not be > displayed at all, right? What will trigger its display when it > becomes non-empty? Sorry if I'm missing something obvious. > > ​​The buffer will be displayed by comint-make-newly-written-buffer-visible, which I've added to the default value > of comint-preoutput-filter-functions. At present the buffer name is hard coded there, so this will only work for > "*Async Shell Command*". > > So, to allow the user to be able to change the name, I suppose another user option would need to be > introduced. > > However, that is beyond the scope of this bug, which is simply to change the behaviour for asynchronous > uses of shell-command. The name comint-make-newly-written-buffer-visible doesn't imply that it only handles that single buffer. We could, of course, change the name so that it did, but IMO making the function customizable wrt buffers it handles would be a much better way.