bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window

[martin rudalics]

> A bit inconsistent, though, isn't it? Stealing space from the lower,
> returning to the upper.

When you resize the selected window you try to steal from/give to the
lower window in order to not clobber the window-start position of the
selected window.  When you delete a window you return space to the upper
one because that's where the space usually came from.  That's just my
interpretation of the behavior, though.

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

(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?

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

>> Don't we?  How would the (when resize ...) check affect the rest?  And
>> keep in mind that any resize operation has to take into account that the
>> frame configuration or size has changed in the meantime.
>
> Eh, I meant the comparison will blow up, it's above the condition-case:
>
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>   /=(nil 42)
>   eval((/= nil 42) nil)

I see.  This would have to be fixed anyway if the third element of the
quit-restore parameter is not set in `display-buffer-record-window'.

>>  > I'm fine with either behavior (not resizing or properly restoring),
>> but
>>  > `vc-diff' is not the only culprit. `vc-log-print' also does the
>>  > shrinking, although it's harder to observe.
>>
>> What and where is `vc-log-print'?
>
> Sorry, `vc-print-log'. C-x v l.

It's in `vc-log-internal-common', I see.

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

martin