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: Sun, 01 Jul 2012 03:18:13 +0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1

On 30.06.2012 13:09, martin rudalics wrote:
`even-window-heights' is one of these options pertaining to the classic
two windows one-above-the-other frame layout.  It should be redesigned
to handle side-by-side windows and is largely obsolete anyway because
you can now customize `window-combination-resize' instead.

How is it obsolete? As far as I can see, neither of the two possible values of `window-combination-resize' says "don't resize my existing windows until specifically asked".

 > I don't think I've ever used `temp-buffer-resize-mode', but if it's a
 > minor mode that a user has to enable explicitly, it should be fine if it
 > overrides the value of `resize-windows-for-display'.
 > Please note that `temp-buffer-resize-mode' already does the sane thing:
 > it only resizes the window if the window is new and not reused.

`temp-buffer-resize-mode' adds `resize-temp-buffer-window' to
`temp-buffer-window-show-hook' so it resizes the window even when it's
reused.  Or do I miss something?

Actually yes, I haven't tested it properly the last time.
It can shrink the window to make it fit the buffer, but it restores the window's size when it's done, which is the important thing.

 > To answer you question in the last message:
 >
 >  >> !       (let ((resize-windows-for-display nil))
 >  >> !  (pop-to-buffer (current-buffer)))
 >  >
 >  > Here you explicitly override the user option - is that intentional?
 >
 > It's intentional, because `vc-diff-internal' calls `pop-to-buffer'
 > before the diff command returns its full output, so the window height
 > adjustment happens in `vc-diff-finish' which runs after the process
 > returns. So you might want to account for this usage.

I don't recall the details but we always had a chicken-and-egg problem
here: When you fill a buffer before displaying it you can't make its
line breaks suit the window used for it.  When you display it first, you
can't make the window suit the line breaks of the buffer.  And the
number of line breaks determines the height of the region to display.

Do you mean auto-filling, as in, "inserting hard newlines"? I don't think diff-mode does that. It does pop a window immediately, but probably just because it would be weird to see a window pop up only after the diff command finishes (if that happens after some time has passed).

 > Regarding "two similar approaches", I think just having an off by
 > default `even-window-heights` variable and `temp-buffer-resize-mode' may
 > satisfy more or less everyone, except there'd at least need to be a way
 > to make shrinking asynchronous, as per above.

Since I don't use `vc-diff' I can't really comment on how it should
behave (I practically always use side-by-side windows for watching
diffs).  Is anyone interested in the resizing behavior at all?  Couldn't
we use the `quit-restore' window parameter to restore the original size
of the window?

We probably could, if solving only this particular case is okay. As far as VC package goes, we'd need to do that in `vc-diff-internal' and in all (?) callers of `vc-log-internal-common'.

-- Dmitry





reply via email to

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