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

Previous Next

Package: emacs;

Reported by: Dmitry Gutov <dmitry <at> gutov.dev>

Date: Thu, 19 Jun 2025 02:20:02 UTC

Severity: normal

Full log


View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: martin rudalics <rudalics <at> gmx.at>, 78835 <at> debbugs.gnu.org
Subject: 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?)




This bug report was last modified 29 days ago.

Previous Next


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