From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Madhu Newsgroups: gmane.emacs.devel Subject: Re: master 18b680cfd1: Fix bug#52467 by adding a new custom variable 'display-comint-buffer-action' Date: Sun, 02 Jan 2022 21:51:27 +0530 Message-ID: References: <164073060906.21430.4993248796177370312@vcs2.savannah.gnu.org> <20211228223009.6D0BAC002EE@vcs2.savannah.gnu.org> <871r1v8nhf.fsf@gnus.org> <83ilv7jqm7.fsf@gnu.org> <6a9cd581-1630-4a95-62c4-419603561072@gmx.at> <3499cedf-b170-3045-873d-d45d2972ae13@gmx.at> <0f492ac4-4167-5448-2c74-a5f67950eae4@yandex.ru> <2de2323b-6d34-9263-776b-dbeff036f8f4@gmx.at> <87zgog68ni.fsf@gnus.org> <8dfc6f22-d331-e7c1-b536-2d374197528f@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="25644"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Cancel-Lock: sha1:esSG17Q7v/uVCkvzxzJDzJv6I2o= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 02 17:24:12 2022 Return-path: Envelope-to: ged-emacs-devel@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 1n43eU-0006TC-Kw for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Jan 2022 17:24:10 +0100 Original-Received: from localhost ([::1]:60490 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n43eT-00035R-Lc for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Jan 2022 11:24:09 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:59116) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n43bp-0001MJ-F2 for emacs-devel@gnu.org; Sun, 02 Jan 2022 11:21:25 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]:35940) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n43bn-0003KT-Sd for emacs-devel@gnu.org; Sun, 02 Jan 2022 11:21:25 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1n43bl-0002Nu-1u for emacs-devel@gnu.org; Sun, 02 Jan 2022 17:21:21 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 2 X-Spam_score: 0.2 X-Spam_bar: / X-Spam_report: (0.2 / 5.0 requ) HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:283925 Archived-At: * martin rudalics <8dfc6f22-d331-e7c1-b536-2d374197528f@gmx.at> : Wrote on Fri, 31 Dec 2021 19:41:09 +0100: >> Well, perhaps "unpredictable" is the wrong word. But if we want to make >> these commands behave the same (and I think we do), then some of them >> have to change, and the change committed seems like the most consistent >> and useful one. > > 'pop-to-buffer-same-window' was conceived as a stand-in for > 'switch-to-buffer' so that people could customize it via > 'display-buffer-alist'. Using it as stand-in for 'pop-to-buffer' is > tantamount to using 'switch-to-buffer' as stand-in for 'pop-to-buffer'. I haven't tried your new patch yet but I found pop-to-buffer-same-window + switch-to-buffer-obey-display-actions inadequate for the sort of behaviour required here, I had something like this (with the variable set to t) (defadvice pop-to-buffer-same-window (around reuse-existing-frame-advise (buffer-or-name &optional norecord) activate) (if current-prefix-arg ad-do-it (pop-to-buffer buffer-or-name '((display-buffer-reuse-window display-buffer-same-window) . ((reusable-frames . 0) (inhibit-same-window . nil))) norecord))) This would *for the most part* obey the customizations via pop-up-frames and pop-up-windows or via display-buffer-alist (as the manual now suggests. the latter is not easy to customize 'graphic-only, and fails in many ways with packages like consult and transient) > I'm not sure whether we should want to "make these commands behave the > same". But if we do, we have to provide some _simple_ knob to let users > get the old behavior without having to think about how to match names of > buffers they possibly never cared about with the help of a regular > expression.