bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dmitry Gutov
Subject: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window
Date: Tue, 03 Jul 2012 16:48:13 +0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]