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: Tue, 27 Dec 2016 22:21:11 +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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c062bd213d7d80544ab4577 X-Trace: blaine.gmane.org 1482877342 2934 195.159.176.226 (27 Dec 2016 22:22:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Dec 2016 22:22:22 +0000 (UTC) Cc: 18133@debbugs.gnu.org, Juri Linkov To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 27 23:22:16 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 1cM08M-0007Vv-9q for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Dec 2016 23:22:14 +0100 Original-Received: from localhost ([::1]:56477 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cM08K-0007d0-RD for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Dec 2016 17:22:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37913) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cM08E-0007ck-5x for bug-gnu-emacs@gnu.org; Tue, 27 Dec 2016 17:22:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cM08A-0005Ld-8A for bug-gnu-emacs@gnu.org; Tue, 27 Dec 2016 17:22:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41949) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cM08A-0005LZ-5S for bug-gnu-emacs@gnu.org; Tue, 27 Dec 2016 17:22:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cM08A-0007NE-0w for bug-gnu-emacs@gnu.org; Tue, 27 Dec 2016 17:22: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: Tue, 27 Dec 2016 22:22:01 +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.148287728128294 (code B ref 18133); Tue, 27 Dec 2016 22:22:01 +0000 Original-Received: (at 18133) by debbugs.gnu.org; 27 Dec 2016 22:21:21 +0000 Original-Received: from localhost ([127.0.0.1]:57348 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cM07V-0007MH-93 for submit@debbugs.gnu.org; Tue, 27 Dec 2016 17:21:21 -0500 Original-Received: from mail-qk0-f169.google.com ([209.85.220.169]:35691) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cM07S-0007M3-1o for 18133@debbugs.gnu.org; Tue, 27 Dec 2016 17:21:18 -0500 Original-Received: by mail-qk0-f169.google.com with SMTP id u25so220520735qki.2 for <18133@debbugs.gnu.org>; Tue, 27 Dec 2016 14:21:18 -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=ZKxA9PKFbVO/qryIUxT5g1Qc2BS6dGEumkxCS260HKA=; b=KogqBeHAysnJ/K1DFixkJLE60zHyfLaTHpm1c5IX+voRfaVfp+GjoIrsQo2jvmgpxv oFLJItjvn2nwg7U4O2jGXmyajgjNDOxqwyJateZWtrzaKwqHooexYW9QOmMvPKlp2DjY 7hqIhGDaCEWEYA7g/mweRPGhaK3NjgGOj1Oz0= 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=ZKxA9PKFbVO/qryIUxT5g1Qc2BS6dGEumkxCS260HKA=; b=mCrvCF9xY2jgXFwfhEeoQ2fsu24/k1S/irnT2Da65jfK64fQcPXRKyE5Ab2Bxw1KlX dzTu+0Yc1snY2o+cXYJm46FG0y1nc28+HuTWggP60Lzn/hCnTPEkManl10ewLtYfn6SI Tj2+YN9+q8YfFkrTG/z37aUE4ZJBVXq6ILMK0ZQzlTn6OJ56H91vskpoumTB6RUv1V77 YoDh2bv+3uy+d6Mb6d3fG0DtG3BQgiSp7Efzes3SUXg0AO9Sqpm9bmJTn7vEAJVnlbwH pMTNjBAPCnJC6zIbOH7pVphZGaXoSTBhMvhtBb1FH/EIxOhHpPtbItVi6354A3g+/Fpd P6LQ== X-Gm-Message-State: AIkVDXK9IuLaIVNhABzAUlo9mN2VXLZF9iskbYW308LzJ9nwzbeaaNoYbscAh3SNjruDHfIkhbEmmj8XspKB0kl6 X-Received: by 10.55.165.141 with SMTP id o135mr32545475qke.119.1482877272560; Tue, 27 Dec 2016 14:21:12 -0800 (PST) Original-Received: by 10.140.88.51 with HTTP; Tue, 27 Dec 2016 14:21:11 -0800 (PST) In-Reply-To: <83eg0twwje.fsf@gnu.org> 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:127508 Archived-At: --94eb2c062bd213d7d80544ab4577 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 27 December 2016 at 09:28, Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Tue, 27 Dec 2016 09:01:32 +0000 > > Cc: Juri Linkov , martin rudalics , > 18133@debbugs.gnu.org > > > > > +(defun comint-make-newly-written-buffer-visible (string process) > > > + "Make the output buffer visible when output is added to an empty > buffer. > > > +Useful in `comint-preoutput-filter-functions'." > > > + (let ((buffer (process-buffer process))) > > > + (when (and (=3D 0 (buffer-size buffer)) > > > + (string-match-p "\\*Async Shell Command\\*" > > > + (buffer-name buffer))) > > > + (display-buffer (process-buffer process)))) > > > + string) > > > > Why are we hard-coding a certain buffer name in a function that is > > supposed to be more general, judging by its name and doc string? > > > > =E2=80=8BI found it hard-coded several times in other places, so I hard= -coded it > here. What do you suggest? > > I don't see it hard-coded in any context such as this. > =E2=80=8BI'm not quite sure what you mean by "in any context such as this".= I see the string repeated in source code, and never assigned to a variable name. This seems OK, since strings and symbols are pretty much interchangeable when of this sort (e.g. not internationalised).=E2=80=8B > I think the regexp against which buffer names are matched in > comint-make-newly-written-buffer-visible should be customizable, with > "*Async Shell Command*" being (in) the default value. > This is already the case.=E2=80=8B And another question: where's the user option to turn this feature on > or off (including the default being off)? > =E2=80=8BM-x=E2=80=8B customize-variable RET display-buffer-alist RET You can tick/untick the option for "*Async Shell Command*", and, when it is ticked, the regexp can be edited. --=20 http://rrt.sc3d.org --94eb2c062bd213d7d80544ab4577 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = 27 December 2016 at 09:28, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Reuben Thomas <rrt@sc3d.org>
> Date: Tue, 27 Dec 2016 09:01:32 +0000
> Cc: Juri Linkov <juri@linkov.net= >, martin rudalics <rudalics@g= mx.at>, 18133@debbugs.gnu.o= rg
>
>=C2=A0 > +(defun comint-make-newly-written-buffer-visible (stri= ng process)
>=C2=A0 > + "Make the output buffer visible when output is added= to an empty buffer.
>=C2=A0 > +Useful in `comint-preoutput-filter-functions'.&qu= ot;
>=C2=A0 > + (let ((buffer (process-buffer process)))
>=C2=A0 > + (when (and (=3D 0 (buffer-size buffer))
>=C2=A0 > + (string-match-p "\\*Async Shell Command\\*"
>=C2=A0 > + (buffer-name buffer)))
>=C2=A0 > + (display-buffer (process-buffer process))))
>=C2=A0 > + string)
>
>=C2=A0 Why are we hard-coding a certain buffer name in a function that = is
>=C2=A0 supposed to be more general, judging by its name and doc string?=
>
> =E2=80=8BI found it hard-coded several times in other places, so I har= d-coded it here. What do you suggest?

I don't see it hard-coded in any context such as this.

=E2=80=8BI'm not quite sure what you mean by "in any contex= t such as this". I see the string repeated in source code, and never a= ssigned to a variable name. This seems OK, since strings and symbols are pr= etty much interchangeable when of this sort (e.g. not internationalised).= =E2=80=8B
=C2=A0
I thin= k the regexp against which buffer names are matched in
comint-make-newly-written-buffer-visible should be customizable, with<= br> "*Async Shell Command*" being (in) the default value.

This is already the case.=E2=80=8B

And another question: where's the user option to = turn this feature on
or off (including the default being off)?

=E2=80=8BM-x=E2=80=8B customize-variable RET display-buffer-alist RE= T

You can tick/untick the= option for "*Async Shell Command*", and, when it is ticked, the = regexp can be edited.

--
http://rrt.sc3d.org
--94eb2c062bd213d7d80544ab4577--