From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#64394: [PATCH] Fix `async-shell-command-display-buffer' display Date: Sun, 02 Jul 2023 21:03:58 +0300 Organization: LINKOV.NET Message-ID: <86cz1axjtl.fsf@mail.linkov.net> References: <873528cuoe.fsf@eliza.sh> <833528rt62.fsf@gnu.org> <87h6qo6pbz.fsf@eliza.sh> <02b09ae9-52ba-4dab-02a2-adf0ef5a4d28@gmx.at> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10940"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) Cc: Eliza Velasquez , Eli Zaretskii , 64394@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 02 20:18:23 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qG1eR-0002e3-21 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 02 Jul 2023 20:18:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qG1e8-00022a-9F; Sun, 02 Jul 2023 14:18:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qG1e6-0001vo-Tl for bug-gnu-emacs@gnu.org; Sun, 02 Jul 2023 14:18:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qG1e6-0007Fz-H9 for bug-gnu-emacs@gnu.org; Sun, 02 Jul 2023 14:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qG1e6-0002q5-9K for bug-gnu-emacs@gnu.org; Sun, 02 Jul 2023 14:18:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 02 Jul 2023 18:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64394 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 64394-submit@debbugs.gnu.org id=B64394.168832183310826 (code B ref 64394); Sun, 02 Jul 2023 18:18:02 +0000 Original-Received: (at 64394) by debbugs.gnu.org; 2 Jul 2023 18:17:13 +0000 Original-Received: from localhost ([127.0.0.1]:32772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qG1dJ-0002oY-0m for submit@debbugs.gnu.org; Sun, 02 Jul 2023 14:17:13 -0400 Original-Received: from relay7-d.mail.gandi.net ([217.70.183.200]:48199) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qG1dG-0002o8-Bw for 64394@debbugs.gnu.org; Sun, 02 Jul 2023 14:17:11 -0400 X-GND-Sasl: juri@linkov.net X-GND-Sasl: juri@linkov.net X-GND-Sasl: juri@linkov.net X-GND-Sasl: juri@linkov.net Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id 4230620009; Sun, 2 Jul 2023 18:17:02 +0000 (UTC) In-Reply-To: <02b09ae9-52ba-4dab-02a2-adf0ef5a4d28@gmx.at> (martin rudalics's message of "Sun, 2 Jul 2023 09:09:37 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:264496 Archived-At: >>> I'm probably missing something, but how can display-buffer fail to >>> support any action function, such as display-buffer-no-window? >>> >>> Martin, what am I missing here? > > We may have to ask Juri, he conceived the "allow-no-window" concept. I don't remember the details why we decided to design it that way. But now I don't see why not enable allow-no-window by default, i.e. why not to make it opt-out instead of opt-in. >> Technically it seems that you can add `(allow-no-window . t)' to >> `display-buffer-alist' to always force the buffer never to appear, but >> that doesn't seem at all like its intended use. > > Maybe "force" is too strong here. You can "force" it by adding an > 'allow-no-window' entry to the alist _and_ a 'display-buffer-no-window' > action in a position that precedes any other display buffer action. Indeed, it's possible to add 'allow-no-window' in customization: (setq display-buffer-alist '(("\\*Async Shell Command\\*" display-buffer-no-window (allow-no-window . t)))) (setq async-shell-command-display-buffer nil) > I suppose (Juri will correct me) that this snippet in 'shell-command' > > (if async-shell-command-display-buffer > ;; Display buffer immediately. > (display-buffer buffer '(nil (allow-no-window . t))) <<<<< > ;; Defer displaying buffer until first process output. > ;; Use disposable named advice so that the buffer is > ;; displayed at most once per process lifetime. > (let ((nonce (make-symbol "nonce"))) > (add-function :before (process-filter proc) > (lambda (proc _string) > (let ((buf (process-buffer proc))) > (when (buffer-live-p buf) > (remove-function (process-filter proc) > nonce) > (display-buffer buf)))) <<<<< > `((name . ,nonce))))))) > > adding an 'allow-no-window' entry if and only if > 'async-shell-command-display-buffer' is non-nil is responsible for the > behavior Eliza sees. I have no idea whether adding such an entry in the > second case could cause problems. We could give > 'async-shell-command-display-buffer' a third value, say 'allow-no-window > and, if a user has set it to that value, have 'shell-command' add an > 'allow-no-window' entry in the second case too. I think it's a plain bug that the first call of 'display-buffer' sets 'allow-no-window' to t, but the second call doesn't. These two 'display-buffer' calls were intended to do the same thing. Only the second call is delayed until input arrives.