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

Previous Next

Full log

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

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

> 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

Previous Next

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