[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window
From: |
martin rudalics |
Subject: |
Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window |
Date: |
Mon, 02 Jul 2012 09:00:04 +0200 |
> I don't understand what "implicitly" means here. Will
> `even-window-heights' be nil by default?
My description was sloppy and inaccurate.
> From what I understand in `window-combination-resize' docstring, its
> value decides whether splitting a window borrows space only from
> adjacent window, or from all windows in a "combination" (so they all get
> resized). For that to happen, a window splitting should occur, right?
> But when we're displaying a buffer in pre-existing window, no splitting
> occurs, just resizing.
> And `even-window-heights' controls whether it should be resized at all.
IIUC, the case we're talking about is that of a split frame where one
window gets reused. Now, with `window-combination-resize' non-nil,
`display-buffer' practically always makes a new window in such a case
because it can steal space from both existing windows. Quitting or
deleting the new window will restore the sizes of the original windows
regardless of whether `temp-buffer-resize-mode' has been used or not.
>> We could simply remove the `temp-buffer-resize-mode' check in
>> `quit-window'. I hardly understand what implications this might have.
>
> I think it's just trying to making sure that (nth 3 quad) is of the
> right type, so that the comparison doesn't blow up.
No (at least not as far as I originally conceived it). My idea was as
follows:
(1) When `temp-buffer-resize-mode' is non-nil and the window size has
changed, chances are that the change was caused by
`temp-buffer-resize-mode' so it seems pretty safe to rescind that
change.
(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.
But maybe my conception was flawed.
> If I enable temp-buffer-resize-mode before doing vc-diff, after I quit
> the window, its size does get restored.
It should be sufficient to set the variable `temp-buffer-resize-mode'
locally in that buffer.
> Also, (nth 3 quad) is integer at that point even temp-buffer-resize-mode
> is disabled, so the mode check doesn't make sense.
> To be safe, though, we could replace it with `integerp' call.
Yes, but the `condition-case' should handle any problems with it.
In any case, we have to cater for the case where people (I'm not sure
whether I got Andreas right) want to disable adjusting the window in the
first place. So I really think we should simply special-case this by
providing some option like `vc-fit-diff-window-to-buffer' and adjust the
window only if that variable has a non-nil value. If it's non-nil, we
can either
(1) set `temp-buffer-resize-mode' locally in such buffers, or
(2) provide yet another variable which, when set, causes `quit-window'
to re-resize the window (we could misuse `even-window-heights' for
this purpose), or
(3) re-resize the window as in your patch.
WDYT?
martin
- Re: bug#11810: 24.1.50; `vc-diff' shrinks pre-existing window,
martin rudalics <=