From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Reuben Thomas Newsgroups: gmane.emacs.bugs Subject: bug#18133: Suppressing asynchronous command output Date: Fri, 30 Dec 2016 18:28:46 +0000 Message-ID: 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> <8737h6z63w.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1135da066e5f500544e45fcf X-Trace: blaine.gmane.org 1483122559 20803 195.159.176.226 (30 Dec 2016 18:29:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 30 Dec 2016 18:29:19 +0000 (UTC) Cc: 18133@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 30 19:29:13 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 1cN1vQ-0004GE-SV for geb-bug-gnu-emacs@m.gmane.org; Fri, 30 Dec 2016 19:29:09 +0100 Original-Received: from localhost ([::1]:41090 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cN1vV-0005Df-JW for geb-bug-gnu-emacs@m.gmane.org; Fri, 30 Dec 2016 13:29:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47768) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cN1vO-0005Da-Ra for bug-gnu-emacs@gnu.org; Fri, 30 Dec 2016 13:29:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cN1vK-0007J7-TH for bug-gnu-emacs@gnu.org; Fri, 30 Dec 2016 13:29:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45195) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cN1vK-0007Iy-P8 for bug-gnu-emacs@gnu.org; Fri, 30 Dec 2016 13:29:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cN1vK-0006yD-B4 for bug-gnu-emacs@gnu.org; Fri, 30 Dec 2016 13:29:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Reuben Thomas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 Dec 2016 18:29: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.148312253526778 (code B ref 18133); Fri, 30 Dec 2016 18:29:02 +0000 Original-Received: (at 18133) by debbugs.gnu.org; 30 Dec 2016 18:28:55 +0000 Original-Received: from localhost ([127.0.0.1]:60594 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cN1vD-0006xq-HZ for submit@debbugs.gnu.org; Fri, 30 Dec 2016 13:28:55 -0500 Original-Received: from mail-qt0-f182.google.com ([209.85.216.182]:33684) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cN1vB-0006xd-9D for 18133@debbugs.gnu.org; Fri, 30 Dec 2016 13:28:53 -0500 Original-Received: by mail-qt0-f182.google.com with SMTP id p16so397332665qta.0 for <18133@debbugs.gnu.org>; Fri, 30 Dec 2016 10:28:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JmXwx9hYFeG5Zk61+X0WwBCJtFveh+6XMwH1MacottU=; b=RHF1EsIZuT6yMBZSVYThn4G7MBaQ9pZlxm5h4ykik+niT0W/An1Izg0Obbg8SxC4kr wMLBbV0gnI/57VHFHR53VjSABmvlJLamFiE+c9caUBv6R7izWYOHIfUY65ZjVZK32PT/ zd1d2O4wtPSbfv+ZeTHnQGvMcBtic9hr2LrLY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JmXwx9hYFeG5Zk61+X0WwBCJtFveh+6XMwH1MacottU=; b=n0Z7u7s9kscg5/wq92Qww500o7FbnnrLdLzQAhK9NKrrruHnYP2BXXXpth396IuSWl 4DU2PhpmyDPa5c2Aq3GLs2kDQUbV61+nU1oL13dhhG0Jx3tM8DSdSb7DJ75LMFIctOXp eZ+Q5p7fF8aYpsavlBY8/QjhxhTLUnt4nud9jf2M2xlDVVHmnD8NYd6vK6fCsK7EunyE ERchhRu+bbnhjcn+N3ORqh8niogNszhdg+TRgqK9VYIaGX8gMgzsEwvZKcUAEL9EVtcR e+zImv9XrZKj3pROWA9exA3YlJuanLYKBEqVyIZIOjNwK3dC+FY5mfb5or/2k/0jD7Cv EE5w== X-Gm-Message-State: AIkVDXK6N46xOGXSSY/Jdv73OLekXPRlL4l9ktMZCqg6jAS9pZ/L2NtEAqbJZMT+2fv9LZYeKnfveQZZipMINxeq X-Received: by 10.200.47.38 with SMTP id j35mr44345188qta.136.1483122527848; Fri, 30 Dec 2016 10:28:47 -0800 (PST) Original-Received: by 10.140.88.51 with HTTP; Fri, 30 Dec 2016 10:28:46 -0800 (PST) In-Reply-To: <8737h6z63w.fsf@mail.linkov.net> 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:127587 Archived-At: --001a1135da066e5f500544e45fcf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29 December 2016 at 23:08, Juri Linkov wrote: > > 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*". > > Maybe you could construct a lambda in =E2=80=98shell-command=E2=80=99 > containing the buffer name dynamically bound to the value of > (or output-buffer "*Async Shell Command*"), then set this lambda > to the process-filter, as we already do in =E2=80=98shell-command=E2=80= =99 with > > (set-process-filter proc 'comint-output-filter) > > i.e. something like > > (set-process-filter proc `(lambda (process string) > (when ... > (display-buffer ,(or output-buffer "*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. > > If the above solution will work, then we'll need a new customizable > variable > like =E2=80=98async-shell-command-display-buffer=E2=80=99. And also =E2= =80=98display-buffer=E2=80=99 in > =E2=80=98shell-command=E2=80=99 will need to be adjusted in the way recom= mended by Martin. > =E2=80=8BI tried to integrate these changes with Eli's feedback, but I got = stuck. "The way recommended by Martin" involves a new minor mode, async-shell-lazy-pop-up-mode, which I tried to avoid; Eli didn't seem to support its addition, either. I'm not sure what the variable async-shell-command-display-buffer is supposed to contain. (It does not seem to be the name of the buffer to be matched.) I am unclear what goes in the ellipsis after "when" in the sample code above; it seems to imply a test for whether the buffer should be displayed, but I already handled that in my patch with the preoutput-filter function. So, the above seems to be an alternative suggestion to Eli's, rather than a complementary one, as I first thought. It would be good if you experts could agree on an approach that I could quickly implement. I'm out of my depth here as far as design goes, and while I'm learning a bit, I'm not sure it's a good use of the total amount of time we seem to be expending between us! --=20 http://rrt.sc3d.org --001a1135da066e5f500544e45fcf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = 29 December 2016 at 23:08, Juri Linkov <juri@linkov.net> wrote= :
> The buffer will be displayed by = comint-make-newly-written-buffer-visible,
> which I've added to the default value of comint-preoutput-filter-<= wbr>functions.
> At present the buffer name is hard coded there, so this will only work= for
> "*Async Shell Command*".

Maybe you could construct a lambda in =E2=80=98shell-command=E2=80= =99
containing the buffer name dynamically bound to the value of
(or output-buffer "*Async Shell Command*"), then set this lambda<= br> to the process-filter, as we already do in =E2=80=98shell-command=E2=80=99 = with

(set-process-filter proc 'comint-output-filter)

i.e. something like

(set-process-filter proc `(lambda (process string)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0(when ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 (display-buffer ,(or output-buffer "*Async Sh= ell Command*")))))

> So, to allow the user to be able to change the name, I suppose another= user
> option would need to be introduced.

If the above solution will work, then we'll need a new customiza= ble variable
like =E2=80=98async-shell-command-display-buffer=E2=80=99.=C2=A0 And a= lso =E2=80=98display-buffer=E2=80=99 in
=E2=80=98shell-command=E2=80=99 will need to be adjusted in the way recomme= nded by Martin.

=E2=80=8BI tried to integrate these changes with Eli's feedback, but= I got stuck.
<= br>
"The w= ay recommended by Martin" involves a new minor mode, async-shell-lazy-= pop-up-mode, which I tried to avoid; Eli didn't seem to support its add= ition, either.
=
I'm no= t sure what the variable async-shell-command-display-buffer is supposed to = contain. (It does not seem to be the name of the buffer to be matched.)

I am unclear what goes in th= e ellipsis after "when" in the sample code above; it seems to imp= ly a test for whether the buffer should be displayed, but I already handled= that in my patch with the preoutput-filter function.

So, the above seems to be an alternative sugge= stion to Eli's, rather than a complementary one, as I first thought.

It would be good if you exp= erts could agree on an approach that I could quickly implement. I'm out= of my depth here as far as design goes, and while I'm learning a bit, = I'm not sure it's a good use of the total amount of time we seem to= be expending between us!

--
http= ://rrt.sc3d.org
--001a1135da066e5f500544e45fcf--