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

Previous Next

Full log

View this message in rfc822 format

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

>>  > 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'.

Sure.  But as I proposed earlier we could have handled this by setting
`temp-buffer-resize-mode' to t in the diff-buffer.

> `even-window-heights' could have contributed in another case, if my
> windows were not of equal height already.

`even-window-heights' is customizable so it's not a primary issue.  But
we could undo the evening in `quit-window'.

>> 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.

Unless it's an interactive call of
`shrink-window-if-larger-than-buffer' probably.

>> `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.

`adjust-window-trailing-edge' drags an edge between two windows and
usually resizes the two windows adjacent to the edge, for example, when
mouse-dragging the mode-line.  Hence we have two candidates for clearing
a quit-restore parameter's size element.

> 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.

Why?  I set the buffer-local value only when `temp-buffer-resize-mode'
is off.  When it's on I don't assign a buffer-local value.  The
re-resize code in `quit-window' would trigger when either the local or
the global value is t.

Anyway, this would only handle the re-resizing when quitting the vc-diff
buffer.  It would not handle the case where people don't want any
resizing.  Maybe vc-diff should shrink iff `temp-buffer-resize-mode' is
on.

>>  > 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.

Remember that the vc-diff buffer is not a temporary buffer.  Currently,
in order to trigger automatic resizing of temporary buffer windows you
have to use `with-output-to-temp-buffer'.  If vc-diff had used that
macro, the entire resizing issue would have been handled already.
Another way is to explicitly call `resize-temp-buffer-window' and set
`temp-buffer-resize-mode' t in that buffer.

martin

Previous Next

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