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.

Message #20 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: Sun, 13 Jul 2025 14:53:28 +0300

On 21/06/2025 05:23, Dmitry Gutov wrote:
>> 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.

Just an update: I've seen the prompt today and moved to step 2 (removed 
the 'unless horizontal' condition).

Message #23 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: Sun, 13 Jul 2025 17:28:50 +0300

On 13/07/2025 14:53, Dmitry Gutov wrote:
> On 21/06/2025 05:23, Dmitry Gutov wrote:
>>> 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.
> 
> Just an update: I've seen the prompt today and moved to step 2 (removed 
> the 'unless horizontal' condition).

It didn't seem to help.

Here is a screencast which shows me evaluating the new code with 
eval-buffer (somewhere in the middle of the video), and still seeing the 
prompt when I repeat a certain sequence of actions:

- Show the diff buffer (for window.el), actually.
- Quit it with 'q'.

BTW, despite me answering the prompt 'n' the width gets adjusted anyway.

Hope the link works, if not, I can reupload it somewhere else:

https://jumpshare.com/s/cb8wWgizBFmSSF31fsPr

Message #26 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: Mon, 14 Jul 2025 09:53:19 +0200

>> Just an update: I've seen the prompt today and moved to step 2 (removed the 'unless horizontal' condition).
>
> It didn't seem to help.
>
> Here is a screencast which shows me evaluating the new code with eval-buffer (somewhere in the middle of the video), and still seeing the prompt when I repeat a certain sequence of actions:
>
> - Show the diff buffer (for window.el), actually.
> - Quit it with 'q'.
>
> BTW, despite me answering the prompt 'n' the width gets adjusted anyway.

The 'y-or-n-p' only serves to tell that 'quit-restore-window' actually
does run this part and the problem is there.  Please make a screenshot
before you type 'y' and a screenshot after you typed it so we can see
what goes on.

BTW, how comes that you didn't get prompted for nearly a month?  Did you
never diff buffers in this time?

> Hope the link works, if not, I can reupload it somewhere else:
>
> https://jumpshare.com/s/cb8wWgizBFmSSF31fsPr

In this image I see a frame with two evenly sized windows.  Is there
anything special I'm supposed to see in it?

Whatever it is - if worse comes to worst we can optionally switch off
any such resizing.  It's here to assure that if you

- work with some well laid-out window configuration,

- temporarily show some other buffer in one of its windows, making that
  window small or large for that purpose,

- quit that window,

then the initial configuration should get restored approximately.
Apparently, that misfires in your case but I yet have no idea why.

martin

Message #29 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: Mon, 14 Jul 2025 13:31:23 +0300

On 14/07/2025 10:53, martin rudalics wrote:
>  >> Just an update: I've seen the prompt today and moved to step 2 
> (removed the 'unless horizontal' condition).
>  >
>  > It didn't seem to help.
>  >
>  > Here is a screencast which shows me evaluating the new code with 
> eval-buffer (somewhere in the middle of the video), and still seeing the 
> prompt when I repeat a certain sequence of actions:
>  >
>  > - Show the diff buffer (for window.el), actually.
>  > - Quit it with 'q'.
>  >
>  > BTW, despite me answering the prompt 'n' the width gets adjusted anyway.
> 
> The 'y-or-n-p' only serves to tell that 'quit-restore-window' actually
> does run this part and the problem is there.  Please make a screenshot
> before you type 'y' and a screenshot after you typed it so we can see
> what goes on.

In that particular scenario 'C-x v =' called in the window.el buffer 
popped up the diff buffer which increased the width of the left window 
(not sure why).

And then pressing 'q' in it restored that width.

> BTW, how comes that you didn't get prompted for nearly a month?  Did you
> never diff buffers in this time?

Diff buffers don't usually change window width in my experience. So this 
is a relatively rare scenario. Until it happens and then it can stay a 
while, like the video shows.

So something else in the window configuration precipitated this. I'm not 
sure what.

>  > Hope the link works, if not, I can reupload it somewhere else:
>  >
>  > https://jumpshare.com/s/cb8wWgizBFmSSF31fsPr
> 
> In this image I see a frame with two evenly sized windows.  Is there
> anything special I'm supposed to see in it?

No, just an illustration of the patch having no effect on the behavior - 
whether I answer 'y' or 'n', the outcome is the same.

> Whatever it is - if worse comes to worst we can optionally switch off
> any such resizing.  It's here to assure that if you
> 
> - work with some well laid-out window configuration,
> 
> - temporarily show some other buffer in one of its windows, making that
>    window small or large for that purpose,
> 
> - quit that window,
> 
> then the initial configuration should get restored approximately.
> Apparently, that misfires in your case but I yet have no idea why.

If you could come up with some logging code, I'll be sure to install it. 
Or not logging but something to be called when the problem does happen 
(if something in the configuration history can trigger it?)

Message #32 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: Mon, 14 Jul 2025 16:53:51 +0200

> In that particular scenario 'C-x v =' called in the window.el buffer popped up the diff buffer which increased the width of the left window (not sure why).

You typed C-x v = in a configuration with two side-by-side windows,
right?

> And then pressing 'q' in it restored that width.

If the width changed after displaying the buffer, this is the expected
behavior.

> If you could come up with some logging code, I'll be sure to install
> it. Or not logging but something to be called when the problem does
> happen (if something in the configuration history can trigger it?)

Try the following - it should size the window back iff you type 'y'.

diff --git a/lisp/window.el b/lisp/window.el
index e229562163b..05c33665a8a 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -5457,7 +5457,8 @@ quit-restore-window
       (when (and (integerp (nth 3 quad))
 		 (if (window-combined-p window)
                      (/= (nth 3 quad) (window-total-height window))
-                   (/= (nth 3 quad) (window-total-width window))))
+                   (/= (nth 3 quad) (window-total-width window)))
+		 (y-or-n-p (format "%s ... %s " quit-restore quad)))
 	;; Try to resize WINDOW to its old height but don't signal an
 	;; error.
 	(condition-case nil

Here I can trigger it as follows with emacs -Q: Show window.el in a left
window and a *Help* buffer in the right window.  The ‘quit-restore’
parameter of the *Help* window is

(window window #<window 3 on window.el> #<buffer *Help*>)

Now I do C-x v = in the left window which displays the diff buffer in
the right window but does _not_ change its width.  Next I change the
width of the right window by dragging the mode line divider with the
mouse, type 'q' in the right window and am asked

(window window #<window 3 on window.el> *Help*) ... (*Help* 1 #<marker at 1160 in *Help*> 93) (y or n) y

where the 93 is the previous width which gets restored if I type 'y'.
What do you get?

martin

Message #35 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: Tue, 15 Jul 2025 05:43:12 +0300

On 14/07/2025 17:53, martin rudalics wrote:
>  > In that particular scenario 'C-x v =' called in the window.el buffer 
> popped up the diff buffer which increased the width of the left window 
> (not sure why).
> 
> You typed C-x v = in a configuration with two side-by-side windows,
> right?

Yes. Ones with seemingly equal width.

>  > And then pressing 'q' in it restored that width.
> 
> If the width changed after displaying the buffer, this is the expected
> behavior.

After displaying and/or after quitting it.

>  > If you could come up with some logging code, I'll be sure to install
>  > it. Or not logging but something to be called when the problem does
>  > happen (if something in the configuration history can trigger it?)
> 
> Try the following - it should size the window back iff you type 'y'.
> 
> diff --git a/lisp/window.el b/lisp/window.el
> index e229562163b..05c33665a8a 100644
> --- a/lisp/window.el
> +++ b/lisp/window.el
> @@ -5457,7 +5457,8 @@ quit-restore-window
>         (when (and (integerp (nth 3 quad))
>            (if (window-combined-p window)
>                        (/= (nth 3 quad) (window-total-height window))
> -                   (/= (nth 3 quad) (window-total-width window))))
> +                   (/= (nth 3 quad) (window-total-width window)))
> +         (y-or-n-p (format "%s ... %s " quit-restore quad)))
>       ;; Try to resize WINDOW to its old height but don't signal an
>       ;; error.
>       (condition-case nil

Yeah, I think it works (the message is pretty long, though).

> Here I can trigger it as follows with emacs -Q: Show window.el in a left
> window and a *Help* buffer in the right window.  The ‘quit-restore’
> parameter of the *Help* window is
> 
> (window window #<window 3 on window.el> #<buffer *Help*>)

Not exactly the same value that I see, but I guess that depends on how 
the Help buffer was created anyway.

> Now I do C-x v = in the left window which displays the diff buffer in
> the right window but does _not_ change its width.  Next I change the
> width of the right window by dragging the mode line divider with the
> mouse, type 'q' in the right window and am asked
> 
> (window window #<window 3 on window.el> *Help*) ... (*Help* 1 #<marker 
> at 1160 in *Help*> 93) (y or n) y
> 
> where the 93 is the previous width which gets restored if I type 'y'.
> What do you get?

I get the same (if the windows windows are equal in the beginning). And 
it's somewhat surprising but also logical at the same time.

OT2H, I also see 'vc-diff' resizing the width (evening the windows) if 
its target window takes up less than half of the frame.

Is that a new behavior? I don't think I've noticed it before. Not sure I 
like it in principle either (my widths are usually either even, or more 
rarely uneven with a specific purpose). It also only happens if the 
window spans the whole height, but not inside a vertical split.

Message #38 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: Tue, 15 Jul 2025 10:06:14 +0200

>> You typed C-x v = in a configuration with two side-by-side windows,
>> right?
>
> Yes. Ones with seemingly equal width.
>
>>  > And then pressing 'q' in it restored that width.
>>
>> If the width changed after displaying the buffer, this is the expected
>> behavior.
>
> After displaying and/or after quitting it.

After quitting it.

>> Here I can trigger it as follows with emacs -Q: Show window.el in a left
>> window and a *Help* buffer in the right window.  The ‘quit-restore’
>> parameter of the *Help* window is
>>
>> (window window #<window 3 on window.el> #<buffer *Help*>)
>
> Not exactly the same value that I see, but I guess that depends on how
>  the Help buffer was created anyway.

Right.

>> Now I do C-x v = in the left window which displays the diff buffer in
>> the right window but does _not_ change its width.  Next I change the
>> width of the right window by dragging the mode line divider with the
>> mouse, type 'q' in the right window and am asked
>>
>> (window window #<window 3 on window.el> *Help*) ... (*Help* 1 #<marker at 1160 in *Help*> 93) (y or n) y
>>
>> where the 93 is the previous width which gets restored if I type 'y'.
>> What do you get?
>
> I get the same (if the windows windows are equal in the
> beginning). And it's somewhat surprising but also logical at the same
> time.

'quit-window' is primarily thought to work for short-lived windows where
the configuration before displaying the buffer is still visually present
in the user's mind.  Like restoring a window configuration, but without
deleting newer windows or recreating older ones.

> OT2H, I also see 'vc-diff' resizing the width (evening the windows) if
> its target window takes up less than half of the frame.

I suppose that you want to customize 'even-window-sizes' here.

> Is that a new behavior? I don't think I've noticed it before. Not sure
> I like it in principle either (my widths are usually either even, or
> more rarely uneven with a specific purpose). It also only happens if
> the window spans the whole height, but not inside a vertical split.

Evening widths was added for Emacs 25 - ten years minus one week ago.

martin

Message #41 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, 17 Jul 2025 05:14:52 +0300

On 15/07/2025 11:06, martin rudalics wrote:
>  >> You typed C-x v = in a configuration with two side-by-side windows,
>  >> right?
>  >
>  > Yes. Ones with seemingly equal width.
>  >
>  >>  > And then pressing 'q' in it restored that width.
>  >>
>  >> If the width changed after displaying the buffer, this is the expected
>  >> behavior.
>  >
>  > After displaying and/or after quitting it.
> 
> After quitting it.

After both, in my scenario (first to even the widths, and later to 
restore the previous widths).

>  >> where the 93 is the previous width which gets restored if I type 'y'.
>  >> What do you get?
>  >
>  > I get the same (if the windows windows are equal in the
>  > beginning). And it's somewhat surprising but also logical at the same
>  > time.
> 
> 'quit-window' is primarily thought to work for short-lived windows where
> the configuration before displaying the buffer is still visually present
> in the user's mind.  Like restoring a window configuration, but without
> deleting newer windows or recreating older ones.
> 
>  > OT2H, I also see 'vc-diff' resizing the width (evening the windows) if
>  > its target window takes up less than half of the frame.
> 
> I suppose that you want to customize 'even-window-sizes' here.
> 
>  > Is that a new behavior? I don't think I've noticed it before. Not sure
>  > I like it in principle either (my widths are usually either even, or
>  > more rarely uneven with a specific purpose). It also only happens if
>  > the window spans the whole height, but not inside a vertical split.
> 
> Evening widths was added for Emacs 25 - ten years minus one week ago.

Thanks, I can confirm that for Emacs 30, at least.

And indeed my last example (one I could reproduce) seems like reasonable 
behavior in the light of this explanation.

I think the instances where this had been a bigger problem, were when a 
much older width was restored (older in terms of time). If I see those 
again, I'll report back - though IME those situations are usually more 
transient.

Previous Next

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