GNU bug report logs - #79125
quit-window fails to restore window height in a scenario of buffer reuse

Previous Next

To reply to this bug, email your comments to 79125 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: quit-window fails to restore window height in a scenario of buffer
 reuse
Date: Wed, 30 Jul 2025 04:59:39 +0300

X-Debbugs-CC: rudalics <at> gmx.at, juri <at> linkov.net

Just to preface, it's not a regression against a recent version of 
Emacs. But seeing as we've done some changes in this area lately, such 
as bug#59862, he's a scenario to consider.

1. cd path/to/emacs && src/emacs -Q
2. Visit admin/authors.el (just an example with known vc log message)
3. C-x v g - it creates an even window split, and shows the buffer below.
4. Press 'd' - that shows the diff buffer in the top window.
5. C-x o, to switch to the bottom window again.
6. Move to the second line, press 'l' - that shows vc-change-log buffer 
in the top window, resizing it to fit (shrinking the height to 5 lines).
7. Press 'd'. That shows the vc-diff buffer in the same window, keeping 
the short height. Apparently (*) because the same buffer - though with 
different contents - has been displayed in this window just recently?
8. Press 'q'. The top window shows vc-change-log buffer again, height 
unchanged.
9. Press 'q' again. The top window switches to authors.el but the 
previous height (before the vc-change-log buffer was displayed) is not 
restored, so it's still 5 lines tall. Maybe (**) because the current 
buffer is not the same as what was there before?

Now (*) and (**) are my guesses.

(*) is something that might be fixable in the specific command. But it 
uses 'pop-to-buffer', as is usual.

(**) if can be improved, would be more general change.

Does anybody agree that steps 7 and/or 9 behave suboptimally? Can that 
be improved?

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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: rudalics <at> gmx.at, 79125 <at> debbugs.gnu.org
Subject: Re: bug#79125: quit-window fails to restore window height in a
 scenario of buffer reuse
Date: Wed, 30 Jul 2025 09:59:13 +0300

> 6. Move to the second line, press 'l' - that shows vc-change-log buffer in
> the top window, resizing it to fit (shrinking the height to 5 lines).

I don't like such auto-resizing very much.  I tried to find a way
to disable it in several bug reports, but it always comes back.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Dmitry Gutov <dmitry <at> gutov.dev>, 79125 <at> debbugs.gnu.org
Cc: juri <at> linkov.net
Subject: Re: bug#79125: quit-window fails to restore window height in a
 scenario of buffer reuse
Date: Wed, 30 Jul 2025 10:18:21 +0200

> Does anybody agree that steps 7 and/or 9 behave suboptimally? Can that be improved?

It can be improved but that would be expensive.  'window-prev-buffers'
would have to return the height (and possibly the weight) of the window
in addition to the start and point positions - that is, we'd have to
store five instead of three values per buffer.

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>, Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 79125 <at> debbugs.gnu.org
Subject: Re: bug#79125: quit-window fails to restore window height in a
 scenario of buffer reuse
Date: Wed, 30 Jul 2025 10:18:31 +0200

>> 6. Move to the second line, press 'l' - that shows vc-change-log buffer in
>> the top window, resizing it to fit (shrinking the height to 5 lines).
>
> I don't like such auto-resizing very much.  I tried to find a way
> to disable it in several bug reports, but it always comes back.

Do you have any ideas why 'resize-temp-buffer-window-inhibit' does not
apply here?

martin

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: rudalics <at> gmx.at, 79125 <at> debbugs.gnu.org
Subject: Re: bug#79125: quit-window fails to restore window height in a
 scenario of buffer reuse
Date: Wed, 30 Jul 2025 15:44:33 +0300

On 30/07/2025 09:59, Juri Linkov wrote:
>> 6. Move to the second line, press 'l' - that shows vc-change-log buffer in
>> the top window, resizing it to fit (shrinking the height to 5 lines).
> I don't like such auto-resizing very much.  I tried to find a way
> to disable it in several bug reports, but it always comes back.

I could live without it as well, but if auto-resizing shouldn't apply in 
this scenario, what other scenarios would it apply in?

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: martin rudalics <rudalics <at> gmx.at>, 79125 <at> debbugs.gnu.org
Cc: juri <at> linkov.net
Subject: Re: bug#79125: quit-window fails to restore window height in a
 scenario of buffer reuse
Date: Wed, 30 Jul 2025 15:51:51 +0300

On 30/07/2025 11:18, martin rudalics wrote:
>  > Does anybody agree that steps 7 and/or 9 behave suboptimally? Can 
> that be improved?
> 
> It can be improved but that would be expensive.  'window-prev-buffers'
> would have to return the height (and possibly the weight) of the window
> in addition to the start and point positions - that is, we'd have to
> store five instead of three values per buffer.

That only applies to buffers that were previously displayed in some 
window, right?

Might not affect the total memory use much.

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

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 79125 <at> debbugs.gnu.org
Subject: Re: bug#79125: quit-window fails to restore window height in a
 scenario of buffer reuse
Date: Wed, 30 Jul 2025 20:55:36 +0300

>>> 6. Move to the second line, press 'l' - that shows vc-change-log buffer in
>>> the top window, resizing it to fit (shrinking the height to 5 lines).
>>
>> I don't like such auto-resizing very much.  I tried to find a way
>> to disable it in several bug reports, but it always comes back.
>
> Do you have any ideas why 'resize-temp-buffer-window-inhibit' does not
> apply here?

It seems 'resize-temp-buffer-window-inhibit' is not an user option
since 'window--display-buffer' changes its value.  But I meant
other cases since there is no auto-resizing in Dmitry's test case
while using these settings:

(remove-hook 'vc-diff-finish-functions 'vc-shrink-buffer-window)
(remove-hook 'vc-log-finish-functions 'vc-shrink-buffer-window)

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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: martin rudalics <rudalics <at> gmx.at>, 79125 <at> debbugs.gnu.org
Subject: Re: bug#79125: quit-window fails to restore window height in a
 scenario of buffer reuse
Date: Wed, 30 Jul 2025 20:58:04 +0300

>>> Does anybody agree that steps 7 and/or 9 behave suboptimally? Can that be improved?
>> It can be improved but that would be expensive.  'window-prev-buffers'
>> would have to return the height (and possibly the weight) of the window
>> in addition to the start and point positions - that is, we'd have to
>> store five instead of three values per buffer.
>
> That only applies to buffers that were previously displayed in some window,
> right?

Ideally, auto-resizing should be window+buffer-local.
And as soon as switching from the auto-resized buffer
to another buffer in the same window, the original
window height should be restored.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: dmitry <at> gutov.dev, 79125 <at> debbugs.gnu.org, rudalics <at> gmx.at
Subject: Re: bug#79125: quit-window fails to restore window height in a
 scenario of buffer reuse
Date: Thu, 31 Jul 2025 07:47:14 +0300

> Cc: martin rudalics <rudalics <at> gmx.at>, 79125 <at> debbugs.gnu.org
> From: Juri Linkov <juri <at> linkov.net>
> Date: Wed, 30 Jul 2025 20:58:04 +0300
> 
> >>> Does anybody agree that steps 7 and/or 9 behave suboptimally? Can that be improved?
> >> It can be improved but that would be expensive.  'window-prev-buffers'
> >> would have to return the height (and possibly the weight) of the window
> >> in addition to the start and point positions - that is, we'd have to
> >> store five instead of three values per buffer.
> >
> > That only applies to buffers that were previously displayed in some window,
> > right?
> 
> Ideally, auto-resizing should be window+buffer-local.
> And as soon as switching from the auto-resized buffer
> to another buffer in the same window, the original
> window height should be restored.

It's debatable whether everyone will like this.  For example, my main
code-editing frame always has a window at its bottom where I display
stuff like *Help*, *Apropos*, and commit logs, and I like to keep that
window's height small at all times, once I resize it manually to the
height I like (I have the resize-temp-buffer-window-inhibit option set
to 'vertical').

So if we introduce the above feature, it should be controlled by a
user option.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Dmitry Gutov <dmitry <at> gutov.dev>, Juri Linkov <juri <at> linkov.net>
Cc: 79125 <at> debbugs.gnu.org
Subject: Re: bug#79125: quit-window fails to restore window height in a
 scenario of buffer reuse
Date: Thu, 31 Jul 2025 10:44:55 +0200

> I could live without it as well, but if auto-resizing shouldn't apply
> in this scenario, what other scenarios would it apply in?

In the following cases:

- The window is new.

- The window was already in use for this buffer.

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Dmitry Gutov <dmitry <at> gutov.dev>, 79125 <at> debbugs.gnu.org
Cc: juri <at> linkov.net
Subject: Re: bug#79125: quit-window fails to restore window height in a
 scenario of buffer reuse
Date: Thu, 31 Jul 2025 10:45:26 +0200

>> It can be improved but that would be expensive.  'window-prev-buffers'
>> would have to return the height (and possibly the weight) of the window
>> in addition to the start and point positions - that is, we'd have to
>> store five instead of three values per buffer.
>
> That only applies to buffers that were previously displayed in some window, right?

Yes.

> Might not affect the total memory use much.

Not much likely.  I can try to do it if other attempts to fix this
behavior fail.

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 79125 <at> debbugs.gnu.org
Subject: Re: bug#79125: quit-window fails to restore window height in a
 scenario of buffer reuse
Date: Thu, 31 Jul 2025 10:46:09 +0200

>> Do you have any ideas why 'resize-temp-buffer-window-inhibit' does not
>> apply here?
>
> It seems 'resize-temp-buffer-window-inhibit' is not an user option
> since 'window--display-buffer' changes its value.

I meant why 'window--display-buffer' would not have set it ...

> But I meant
> other cases since there is no auto-resizing in Dmitry's test case
> while using these settings:
>
> (remove-hook 'vc-diff-finish-functions 'vc-shrink-buffer-window)
> (remove-hook 'vc-log-finish-functions 'vc-shrink-buffer-window)

... which explains it, thanks.  So the resizing happens outside the
scope of 'display-buffer'.  We could rewrite 'vc-shrink-buffer-window'
as

(defun vc-shrink-buffer-window (&optional buffer)
  "Call `shrink-window-if-larger-than-buffer' only when BUFFER is visible.
BUFFER defaults to the current buffer."
  (let ((window (get-buffer-window buffer t)))
    (when window
      (let* ((quit-restore (window-parameter window 'quit-restore))
	     (quad (and quit-restore (nth 1 quit-restore))))
	(when (or (not quit-restore) (not (list quad))
		  (eq (window-buffer window) (nth 0 quad)))
	  (shrink-window-if-larger-than-buffer window))))))

but I'm not sure whether people will like it.

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Juri Linkov <juri <at> linkov.net>
Cc: dmitry <at> gutov.dev, 79125 <at> debbugs.gnu.org
Subject: Re: bug#79125: quit-window fails to restore window height in a
 scenario of buffer reuse
Date: Thu, 31 Jul 2025 10:46:20 +0200

> I have the resize-temp-buffer-window-inhibit option set
> to 'vertical'.

That's not an option but an internal variable that allows
'display-buffer' to communicate with 'resize-temp-buffer-window'.
'window--display-buffer' will overwrite whatever you stored there.

martin

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: martin rudalics <rudalics <at> gmx.at>, 79125 <at> debbugs.gnu.org
Subject: Re: bug#79125: quit-window fails to restore window height in a
 scenario of buffer reuse
Date: Fri, 1 Aug 2025 03:34:43 +0300

On 30/07/2025 20:58, Juri Linkov wrote:
>>>> Does anybody agree that steps 7 and/or 9 behave suboptimally? Can that be improved?
>>> It can be improved but that would be expensive.  'window-prev-buffers'
>>> would have to return the height (and possibly the weight) of the window
>>> in addition to the start and point positions - that is, we'd have to
>>> store five instead of three values per buffer.
>> That only applies to buffers that were previously displayed in some window,
>> right?
> Ideally, auto-resizing should be window+buffer-local.
> And as soon as switching from the auto-resized buffer
> to another buffer in the same window, the original
> window height should be restored.

Might conflict with some user customizations (e.g. what if they make 
another window selected right after some of these commands?) or mouse 
clicks (you click in another window, the handler quits the current 
window and resizes it so that your click is not within the current 
window's box, creating an ambiguous situation).

Could work, but sounds like a significant change.

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: martin rudalics <rudalics <at> gmx.at>, Juri Linkov <juri <at> linkov.net>
Cc: 79125 <at> debbugs.gnu.org
Subject: Re: bug#79125: quit-window fails to restore window height in a
 scenario of buffer reuse
Date: Fri, 1 Aug 2025 03:45:11 +0300

On 31/07/2025 11:46, martin rudalics wrote:
> (defun vc-shrink-buffer-window (&optional buffer)
>    "Call `shrink-window-if-larger-than-buffer' only when BUFFER is visible.
> BUFFER defaults to the current buffer."
>    (let ((window (get-buffer-window buffer t)))
>      (when window
>        (let* ((quit-restore (window-parameter window 'quit-restore))
>           (quad (and quit-restore (nth 1 quit-restore))))
>      (when (or (not quit-restore) (not (list quad))

I think you meant 'listp' here.

>            (eq (window-buffer window) (nth 0 quad)))
>        (shrink-window-if-larger-than-buffer window))))))

I've tried it out, and it doesn't seem to fix the original scenario.

If the goal was to implement your explanation from the other subthread:

> In the following cases:
>
> - The window is new.
>
> - The window was already in use for this buffer.

...then it seems fail because it resizes an existing window showing a 
different buffer. Probably because the value of QUAD is 'window', in my 
testing.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Dmitry Gutov <dmitry <at> gutov.dev>, Juri Linkov <juri <at> linkov.net>
Cc: 79125 <at> debbugs.gnu.org
Subject: Re: bug#79125: quit-window fails to restore window height in a
 scenario of buffer reuse
Date: Fri, 1 Aug 2025 10:53:41 +0200

> I've tried it out, and it doesn't seem to fix the original scenario.

Right. The code should be

(defun vc-shrink-buffer-window (&optional buffer)
  "Call `shrink-window-if-larger-than-buffer' only when BUFFER is visible.
BUFFER defaults to the current buffer."
  (let ((window (get-buffer-window buffer t)))
    (when window
      (let* ((quit-restore (window-parameter window 'quit-restore))
	     (quad (and quit-restore (nth 1 quit-restore))))
	(when (or (not quit-restore) (not (listp quad))
		  (eq (window-buffer window) (nth 0 quad)))
	  (shrink-window-if-larger-than-buffer window))))))

> If the goal was to implement your explanation from the other subthread:
>
>  > In the following cases:
>  >
>  > - The window is new.
>  >
>  > - The window was already in use for this buffer.
>
> ...then it seems fail because it resizes an existing window showing a different buffer. Probably because the value of QUAD is 'window', in my testing.

I tried your original scenario and it does not resize windows any more.
C-x v g followed by C-x 1 followed by l or d should work as before.

martin

Previous Next

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