GNU bug report logs -
#78835
Wrong pop-to-buffer behavior after one display-buffer-in-side-window call
Previous Next
Full log
View this message in rfc822 format
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.
This bug report was last modified 28 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.