GNU bug report logs - #78835
Wrong pop-to-buffer behavior after one display-buffer-in-side-window call

Previous Next

To reply to this bug, email your comments to 78835 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: bug-gnu-emacs <at> gnu.org
Subject: Wrong pop-to-buffer behavior after one display-buffer-in-side-window
 call
Date: Thu, 19 Jun 2025 05:19:27 +0300

[Message part 1 (text/plain, inline)]

X-Debbugs-Cc: rudalics <at> gmx.at

Hi Martin and others!

I've started noticing this recently, and it especially gets apparent 
with the new "lexical binding is nil" compilation warning windows which 
use a side window.

A self-contained reproducer took some effort, though.

To use the attached script, load it from the command line like this:

  src/emacs -Q -l d-b-below-bug.el

NOTE: Simply evaluating it from an interactive session won't work 
because it seems to require a particular sequence of buffer/window 
creation operations. It does seem to work to copy it form-by-form to 
evaluate with M-:.

Anyway, the crux of the problem is that after a side window had been 
used, later commands that use pop-to-buffer would reside the window 
unnecessarily, and then not restore the previous size on quit either.

Probably related to the recent changes in window.el, though I haven't 
bisected yet. But this definitely does not reproduce with Emacs 30 or 
earlier releases.

[d-b-below-bug.el (text/x-emacs-lisp, attachment)]

Message #8 received at 78835 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Dmitry Gutov <dmitry <at> gutov.dev>, 78835 <at> debbugs.gnu.org
Subject: Re: bug#78835: Wrong pop-to-buffer behavior after one
 display-buffer-in-side-window call
Date: Thu, 19 Jun 2025 17:06:33 +0200

Hi Dmitry

> Anyway, the crux of the problem is that after a side window had been
> used, later commands that use pop-to-buffer would reside the window
> unnecessarily, and then not restore the previous size on quit either.

It's not specifically related to side windows, a plain 'display-buffer'
should suffice.  The problem is that 'pop-to-buffer' reusing the bs.el
window tries to restore the height of the initial *scratch* window after
first displaying bs.el in it and later splitting it vertically.  In the
patch below I now try to remove the reference to the old height when a
window is split vertically.  Please try it.

Thanks, martin

diff --git a/lisp/window.el b/lisp/window.el
index e372ef8b9bb..f24e581ba1e 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -5899,6 +5899,16 @@ split-window
 	   window (- (if new-parent 1.0 (window-normal-size window horizontal))
 		     new-normal)))

+	(unless horizontal
+	  (let ((quit-restore (window-parameter window 'quit-restore)))
+	    (when quit-restore
+	      (let ((quad (nth 1 quit-restore)))
+		(when (and (listp quad) (integerp (nth 3 quad)))
+		  ;; When WINDOW has a 'quit-restore' parameter that
+		  ;; specifies a previous height to restore, remove that
+		  ;; - it does more harm than good now (Bug#78835).
+		  (setf (nth 3 quad) nil))))))
+
 	(let ((new (split-window-internal
 		    window new-pixel-size side new-normal refer)))
           (window--pixel-to-total frame horizontal)

Message #11 received at 78835 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: martin rudalics <rudalics <at> gmx.at>, 78835 <at> debbugs.gnu.org
Subject: Re: bug#78835: Wrong pop-to-buffer behavior after one
 display-buffer-in-side-window call
Date: Thu, 19 Jun 2025 19:59:00 +0300

Hi Martin!

On 19/06/2025 18:06, martin rudalics wrote:
> It's not specifically related to side windows, a plain 'display-buffer'
> should suffice.  The problem is that 'pop-to-buffer' reusing the bs.el
> window tries to restore the height of the initial *scratch* window after
> first displaying bs.el in it and later splitting it vertically.  In the
> patch below I now try to remove the reference to the old height when a
> window is split vertically.  Please try it.
> 
> Thanks, martin
> 
> diff --git a/lisp/window.el b/lisp/window.el
> index e372ef8b9bb..f24e581ba1e 100644
> --- a/lisp/window.el
> +++ b/lisp/window.el
> @@ -5899,6 +5899,16 @@ split-window
>          window (- (if new-parent 1.0 (window-normal-size window 
> horizontal))
>                new-normal)))
> 
> +    (unless horizontal
> +      (let ((quit-restore (window-parameter window 'quit-restore)))
> +        (when quit-restore
> +          (let ((quad (nth 1 quit-restore)))
> +        (when (and (listp quad) (integerp (nth 3 quad)))
> +          ;; When WINDOW has a 'quit-restore' parameter that
> +          ;; specifies a previous height to restore, remove that
> +          ;; - it does more harm than good now (Bug#78835).
> +          (setf (nth 3 quad) nil))))))
> +

That seems to fix it indeed, thanks.

On a related topic though, another scenario that happens over here is 
'quit-window' restoring a window _width_ to a value that looks 
unexpected to me. For example, just now after applying your patch from a 
buffer, I pressed 'q' and the window (the one on the left in a 
configuration similar to test scenario) got resized to 2/3rds of its 
width. Any ideas about that perhaps?

It is very sporadic, and I don't have any reliable reproduction, so if 
if it doesn't ring a bell, I can try to get more info first.

Message #14 received at 78835 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Dmitry Gutov <dmitry <at> gutov.dev>, 78835 <at> debbugs.gnu.org
Subject: Re: bug#78835: Wrong pop-to-buffer behavior after one
 display-buffer-in-side-window call
Date: Fri, 20 Jun 2025 09:32:47 +0200

> That seems to fix it indeed, thanks.

Pushed to master.

> On a related topic though, another scenario that happens over here is
> 'quit-window' restoring a window _width_ to a value that looks
> unexpected to me. For example, just now after applying your patch from
> a buffer, I pressed 'q' and the window (the one on the left in a
> configuration similar to test scenario) got resized to 2/3rds of its
> width. Any ideas about that perhaps?

Hmm...  Apply

a/lisp/window.el b/lisp/window.el
index f24e581ba1e..b27e1ca56e9 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -5452,6 +5452,10 @@ quit-restore-window
 		 (if (window-combined-p window)
                      (/= (nth 3 quad) (window-total-height window))
                    (/= (nth 3 quad) (window-total-width window))))
+
+	(unless (window-combined-p window)
+	  (y-or-n-p "Adjusting width, continue? "))
+
 	;; Try to resize WINDOW to its old height but don't signal an
 	;; error.
 	(condition-case nil

If and when it asks you, apply

diff --git a/lisp/window.el b/lisp/window.el
index f24e581ba1e..a6f93e067b5 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -5899,15 +5899,14 @@ split-window
 	   window (- (if new-parent 1.0 (window-normal-size window horizontal))
 		     new-normal)))

-	(unless horizontal
-	  (let ((quit-restore (window-parameter window 'quit-restore)))
-	    (when quit-restore
-	      (let ((quad (nth 1 quit-restore)))
-		(when (and (listp quad) (integerp (nth 3 quad)))
-		  ;; When WINDOW has a 'quit-restore' parameter that
-		  ;; specifies a previous height to restore, remove that
-		  ;; - it does more harm than good now (Bug#78835).
-		  (setf (nth 3 quad) nil))))))
+	(let ((quit-restore (window-parameter window 'quit-restore)))
+	  (when quit-restore
+	    (let ((quad (nth 1 quit-restore)))
+	      (when (and (listp quad) (integerp (nth 3 quad)))
+		;; When WINDOW has a 'quit-restore' parameter that
+		;; specifies a previous height to restore, remove that
+		;; - it does more harm than good now (Bug#78835).
+		(setf (nth 3 quad) nil)))))

 	(let ((new (split-window-internal
 		    window new-pixel-size side new-normal refer)))

and tell me if it asks you again.

> It is very sporadic, and I don't have any reliable reproduction, so if
> if it doesn't ring a bell, I can try to get more info first.

I don't recall that I ever tried to restore a previous width too but
apparently I did (and did not even document it).

martin

Message #17 received at 78835 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: martin rudalics <rudalics <at> gmx.at>, 78835 <at> debbugs.gnu.org
Subject: Re: bug#78835: Wrong pop-to-buffer behavior after one
 display-buffer-in-side-window call
Date: Sat, 21 Jun 2025 05:23:23 +0300

On 20/06/2025 10:32, martin rudalics wrote:
>  > That seems to fix it indeed, thanks.
> 
> Pushed to master.

Thanks!

>  > On a related topic though, another scenario that happens over here is
>  > 'quit-window' restoring a window _width_ to a value that looks
>  > unexpected to me. For example, just now after applying your patch from
>  > a buffer, I pressed 'q' and the window (the one on the left in a
>  > configuration similar to test scenario) got resized to 2/3rds of its
>  > width. Any ideas about that perhaps?
> 
> Hmm...  Apply
> 
> a/lisp/window.el b/lisp/window.el
> index f24e581ba1e..b27e1ca56e9 100644
> --- a/lisp/window.el
> +++ b/lisp/window.el
> @@ -5452,6 +5452,10 @@ quit-restore-window
>            (if (window-combined-p window)
>                        (/= (nth 3 quad) (window-total-height window))
>                      (/= (nth 3 quad) (window-total-width window))))
> +
> +    (unless (window-combined-p window)
> +      (y-or-n-p "Adjusting width, continue? "))
> +
>       ;; Try to resize WINDOW to its old height but don't signal an
>       ;; error.
>       (condition-case nil
> 
> If and when it asks you, apply

Thank you. So far I'm running with just this addition for a couple of 
hours, and have not seen the prompt yet (nor the bug with horizontal 
resizing again). Will report back when that happens.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.