emacs-devel
[Top][All Lists]
Advanced

[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



reply via email to

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