GNU bug report logs -
#78835
Wrong pop-to-buffer behavior after one display-buffer-in-side-window call
Previous Next
Full log
Message #35 received at 78835 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 27 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.