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

[martin rudalics <rudalics@gmx.at>]

 > 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