GNU bug report logs - #11810
24.1.50; `vc-diff' shrinks pre-existing window

Previous Next

Full log

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 11810 <at> debbugs.gnu.org
Subject: Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window
Date: Tue, 03 Jul 2012 16:48:13 +0400

On 03.07.2012 11:14, martin rudalics wrote:
>  >>  >> (2) When `temp-buffer-resize-mode' is nil and the window size has
>  >>  >>      changed, the change was probably due to some manual
> intervention
>  >>  >>      probably needed to see more of a buffer originally present
>  >> and it
>  >>  >>      seems better to leave that change alone.
>  >>
>  >> ... in this case we can be sure that the user changed the size so we
>  >> probably should leave it alone.
>  >
>  > That depends on the definition of "the user". In our case, *I* didn't
>  > explicitly resize the window, `vc-diff' did.
>
> Because of `even-window-heights'?  That's something I obviously forgot

Because of `shrink-window-if-larger-than-buffer'.
`even-window-heights' could have contributed in another case, if my 
windows were not of equal height already.

> to handle when quitting a window.  Maybe the best solution is to set the
> 3rd element of the quit-restore parameter iff either
>
> (1) `temp-buffer-resize-mode' is non-nil, or

Maybe just when `fit-window-to-buffer' is called? That would account for 
`shrink-window-if-larger-than-buffer', too.

> (2) `window--even-window-heights' actually did resize the window
>
> and don't do the `temp-buffer-resize-mode' check in `quit-window'.
>
>  > How about clearing (or changing) the 'quit-window parameter in each
>  > command when we're sure that the user won't want to have the size
>  > restored afterwards?
>  > There would be a set of "user-facing" functions that would do that.
>
> `adjust-window-trailing-edge' would be an obvious candidate.  But which
> window's parameter would you clear?  Both?

What's the second one? Please keep in mind that I don't know the 
window.el codebase, I'm just reading the code along the discussion.

>  > How will the temp-buffer-resize-mode null check help in this case?
>  > It's a global minor mode, so it's either t in all buffers, or nil in all
>  > of them.
>
> That's why I would have set `temp-buffer-resize-mode' buffer-locally to
> t.  But it's ugly.

If `temp-buffer-resize-mode' were on, that wouldn't have made a 
difference, would it?
You'd have to locally set `temp-buffer-resize-mode' to nil in all cases 
when you don't want the window size to be restored afterwards, which is 
the same amount of work as clearing 'quit-window parameter.

>  >> I don't know.  I think a vc-diff buffer should be considerded a
>  >> temporary buffer, subject to `temp-buffer-resize-mode'.  Ideally,
>  >> windows of non-temporary buffers are never shrunk automatically.
>  >
>  > Would a window that displayed a normal buffer previously but which now
>  > is displaying a temporary buffer be considered a "window of
>  > non-temporary buffer"?
>
> Only after it displays the normal buffer again.  Why did you ask?

Because that's what at issue here. I think the main two cases of 
automatic shrinking are:
1) "temp buffer" in a window that was created for it,
2) "temp buffer" in a reused window,
and 2) is the reason I filed this bug.

Previous Next

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