From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Constantine Vetoshev Newsgroups: gmane.emacs.bugs Subject: bug#49069: 28.0.50; [PATCH] Use display-buffer for re-builder Date: Thu, 8 Jul 2021 11:38:41 -0700 Message-ID: References: <87r1h1jnf2.fsf@riseup.net> <87a6npf7pr.fsf@riseup.net> <871r90fsoq.fsf@riseup.net> <87o8boy8cd.fsf@riseup.net> <87pmw4tn2t.fsf@mail.linkov.net> <87czs4xqn7.fsf@riseup.net> <87zgv76skf.fsf@mail.linkov.net> <87mtqw6cg8.fsf@riseup.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="60e7463c_68ebc550_5a5" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18098"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 49069@debbugs.gnu.org To: Juri Linkov , Trust me I am a Doctor Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jul 08 22:37:31 2021 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 1m1am2-0004VK-Lw for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 08 Jul 2021 22:37:30 +0200 Original-Received: from localhost ([::1]:37042 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1am1-0000un-Jx for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 08 Jul 2021 16:37:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41668) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m1ala-0000sF-Q1 for bug-gnu-emacs@gnu.org; Thu, 08 Jul 2021 16:37:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46097) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m1ala-0006FI-Gd for bug-gnu-emacs@gnu.org; Thu, 08 Jul 2021 16:37:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m1ala-0006Wk-6X for bug-gnu-emacs@gnu.org; Thu, 08 Jul 2021 16:37:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Constantine Vetoshev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Jul 2021 20:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49069 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed patch Original-Received: via spool by 49069-submit@debbugs.gnu.org id=B49069.162577660225064 (code B ref 49069); Thu, 08 Jul 2021 20:37:02 +0000 Original-Received: (at 49069) by debbugs.gnu.org; 8 Jul 2021 20:36:42 +0000 Original-Received: from localhost ([127.0.0.1]:57643 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1alF-0006WC-La for submit@debbugs.gnu.org; Thu, 08 Jul 2021 16:36:42 -0400 Original-Received: from mail-pf1-f181.google.com ([209.85.210.181]:38542) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1YvL-0003ed-CR for 49069@debbugs.gnu.org; Thu, 08 Jul 2021 14:39:01 -0400 Original-Received: by mail-pf1-f181.google.com with SMTP id j9so664978pfc.5 for <49069@debbugs.gnu.org>; Thu, 08 Jul 2021 11:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=jmNln1YF5Idzw4ocWLrnY2CLfnZrZHR/ncQIUAMhUTQ=; b=JOZTUKeOicjQh9YX82e65+l4VDhf1b91FFJkvd0T8ELKbxzsTZ6qMbiPQ8sT3IuWqK xB9wm/THSOtfa/uD9RHsQcgXPI7KLtdtpOvJ6br57uAiW9M21WaISpq8K36/iGsFfQ4N 9z9MDAeW+Wc6HUUF4Gun6qrYhVQSNrksvgc/X1mxQjtjrBa419TZ90StngidpxIbxery xsz0fcajWW9Jh6uM+HuPkdSfjUZVPid21M3wccOlFBAN+BKEfpPYpoTbq0JFp75ypQWw VXQRy4UKOEGWhvUQ6S6eDanSFqwV2yDriBFTxKxicpuuRNh0bVqFnIn3++ZNF0tMTqwK xn6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=jmNln1YF5Idzw4ocWLrnY2CLfnZrZHR/ncQIUAMhUTQ=; b=na70WKLKGr0RFPVGALhslDZPVtNh027uGS5x7yzvkmsjlUQehXbzzV2oevmz3viovR UyozmUPAys7QXh82ybpHqXFJDFHX9E/hc/hUqodEpxrcLY+0HI2wh4TBzxO4Mjy7PskS GRY0XVjr94mKat7K6d7cK4HMS23VQik3JAyPwcWfBIrlPqRJ+mwtDr+WV5m9/7Za8tWT 78fS7d9OFLSJ1l/XtxXGYwyg3Trgegj5etn3+2r+rLCorDwgm+zszZRI4GC6g4y323u3 5qv1TwtQHzqZ+4PX45H54a50Jyu1qFLMZzRyg3qZ6bs64mMqHsgbLKDEivJ4bmaxYumG TLfQ== X-Gm-Message-State: AOAM530xYmXnF5olMtFElZpiSe0Si584DREfRYW4Wk82Wac5a6bhQ5hi e6aukVzuFRKqYzxsPu8op+w= X-Google-Smtp-Source: ABdhPJxYz2WU5pRxtS3NpEq3zYNVQIaV6MPxPG5mnZ3/23dk+oIrfa0q/gkLzBTfeBPXcIJH0cXflg== X-Received: by 2002:a65:5343:: with SMTP id w3mr33521391pgr.51.1625769533447; Thu, 08 Jul 2021 11:38:53 -0700 (PDT) Original-Received: from [10.0.0.11] ([97.113.122.0]) by smtp.gmail.com with ESMTPSA id r29sm3726936pfq.177.2021.07.08.11.38.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jul 2021 11:38:52 -0700 (PDT) In-Reply-To: <87mtqw6cg8.fsf@riseup.net> X-Readdle-Message-ID: a00181a3-ce6b-42d2-b5c9-a968cfed02ca@Spark X-Mailman-Approved-At: Thu, 08 Jul 2021 16:36:40 -0400 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" Xref: news.gmane.io gmane.emacs.bugs:209710 Archived-At: --60e7463c_68ebc550_5a5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Thank you for bringing this to my attention. I=E2=80=99ll test the displa= y-buffer-base-action approach over the next couple of days, and if it wor= ks as I expect, I=E2=80=99ll update the Perspective README. Note that Juri=E2=80=99s example is not quite the same as mine. Please te= st with this instead: (customize-set-variable 'display-buffer-base-action =C2=A0'((display-buffer-reuse-window display-buffer-same-window) =C2=A0(reusable-frames . t))) That said: it seems to me that rebinding display-buffer-overriding-action= is intended for this very purpose: a judicious, rarely-used, and highly-= targeted change to display-buffer behavior where it is imperative for the= user=E2=80=99s customizations to not have an undesirable effect. On Jul 8, 2021, 08:40 -0700, Trust me I am a Doctor , wrote: > > Juri Linkov writes: > > > > > Sorry, preventing the users from customizing windows is the wrong= thing. > > > > > > I don't know really, let me explain my rational : some users have a= very > > > constrained display-buffer-alist and match =22.*=22. You can see su= ch > > > rational explained at the end of this page : > > > > > > https://github.com/nex3/perspective-el > > > > Thanks for the reference. Now I understand the reason for such absurd= ity > > in org-mode: > > > > (defmacro org-no-popups (&rest body) > > =22Suppress popup windows and evaluate BODY.=22 > > =60(let (pop-up-frames display-buffer-alist) > > ,=40body)) > > > > So different packages are fighting with each other: > > one package recommends using display-buffer-alist to display > > all buffers only in the same window, another package > > throws away user customization on such grounds > > that users might follow such poor recommendations. > > To be fair, blaming the different repositories gives no evidence that > this macro is a reaction to perspective.el > > I CC its maintainer, > Hi Constantine Vetoshev, > While we was discussing window configurations, I introduced the > recommendations of your README that I used to follow in a particular > situation; in regard of the remarks of Juri, you maybe want to update > them=3F > > > The correct way to display all buffers in the same window > > is documented in (info =22(emacs) Window Choice=22) where > > display-buffer-base-action should be customized like this: > > > > (customize-set-variable > > 'display-buffer-base-action > > '((display-buffer-reuse-window display-buffer-same-window))) > > > > And the problem is solved. So please avoid ignoring user customizatio= n > > with display-buffer-overriding-action because users with such > > display-buffer-base-action will be able to customize =22*RE-Builder*=22= with > > display-buffer-alist. > > Ok you convinced me. Thanks for the tip, I installed it on a low-vision= > setup of a knowledge of me. We will see more in detail the differences > that it implies. > > So it seems that the patch of the Thu, 17 Jun 2021 16:50:07 +0200 > was indeed the one we want to keep. > > I tested it again, with : > > (customize-set-variable > 'display-buffer-base-action > '((display-buffer-reuse-window display-buffer-same-window))) > > (setf (alist-get =22*RE-Builder*=22 display-buffer-alist nil nil =23'st= ring=3D) > =60((display-buffer-in-direction) > (direction . top) > (dedicated . t))) > > (re-builder) > > And it obeys to display-buffer-alist, be it for an other > function or others parameters, and keep being functional ... etc. > -- --60e7463c_68ebc550_5a5 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Thank you for bringing this to my attention. I=E2=80= =99ll test the display-buffer-base-action approach over the next couple o= f days, and if it works as I expect, I=E2=80=99ll update the Perspective = README.

Note that Juri=E2=80=99s example is not quite the same as mine. Please te= st with this instead:

(customize-set-variable 'display-buffer-base-action
&=23160;'((display-buffer-reuse-window display-buffer-same-window)
&=23160;(reusable-frames . t)))

That said: it seems to me that rebinding display-buffer-overriding-action= is intended for this very purpose: a judicious, rarely-used, and highly-= targeted change to display-buffer behavior where it is imperative for the= user=E2=80=99s customizations to not have an undesirable effect.
On Jul 8, 2021, 08:40 -0700, Trust = me I am a Doctor <pillule=40riseup.net>, wrote:

Juri Linkov <juri=40linkov.net> writes:

Sorry, preventing the users from customizin= g windows is the wrong thing.

I don't know really, let me explain my rational : some users have a very<= br /> constrained display-buffer-alist and match =22.*=22. You can see such
rational explained at the end of this page :

https://github.com/nex3/perspective-el

Thanks for the reference. Now I understand the reason for such absurdity<= br /> in org-mode:

(defmacro org-no-popups (&rest body)
=22Suppress popup windows and evaluate BODY.=22
=60(let (pop-up-frames display-buffer-alist)
,=40body))

So different packages are fighting with each other:
one package recommends using display-buffer-alist to display
all buffers only in the same window, another package
throws away user customization on such grounds
that users might follow such poor recommendations.

To be fair, blaming the different repositories gives no evidence that
this macro is a reaction to perspective.el

I CC its maintainer,
Hi Constantine Vetoshev,
While we was discussing window configurations, I introduced the
recommendations of your README that I used to follow in a particular
situation; in regard of the remarks of Juri, you maybe want to update
them=3F

The correct way to display all buffers in t= he same window
is documented in (info =22(emacs) Window Choice=22) where
display-buffer-base-action should be customized like this:

(customize-set-variable
'display-buffer-base-action
'((display-buffer-reuse-window display-buffer-same-window)))

And the problem is solved. So please avoid ignoring user customization with display-buffer-overriding-action because users with such
display-buffer-base-action will be able to customize =22*RE-Builder*=22 w= ith
display-buffer-alist.

Ok you convinced me. Thanks for the tip, I installed it on a low-vision setup of a knowledge of me. We will see more in detail the differences that it implies.

So it seems that the patch of the Thu, 17 Jun 2021 16:50:07 +0200
was indeed the one we want to keep.

I tested it again, with :

(customize-set-variable
'display-buffer-base-action
'((display-buffer-reuse-window display-buffer-same-window)))

(setf (alist-get =22*RE-Builder*=22 display-buffer-alist nil nil =23'stri= ng=3D)
=60((display-buffer-in-direction)
(direction . top)
(dedicated . t)))

(re-builder)

And it obeys to display-buffer-alist, be it for an other
function or others parameters, and keep being functional ... etc.
--
--60e7463c_68ebc550_5a5--