Subject: Re: dired-pop-to-buffer in wrong place

From: martin rudalics <[email-masked]>
Date: Fri, 28 Sep 2012 08:32:03 +0200

> A month ago in revno:109790 you added two lines to `dired-pop-to-buffer':
 >
 >   ;; See Bug#12281.
 >   (set-window-start nil (point-min))
 >
 > so I wondered if this is still necessary after the recent redesign of
 > `dired-mark-pop-up' to not cause the same bug as reported in bug#12281.

Hopefully not.  Otherwise _all_ uses of `with-output-to-temp-buffer' and
`with-temp-buffer-window' - which both do (goto-char (point-min)) in the
buffer to be displayed - would be faulty in this regard.

 > Some time ago setting `window-combination-limit' to t allowed
 > `fit-window-to-buffer' not to steal space from the lower window.

Your memory must be wrong.  At least in Emacs 24.1 I can easily shrink
the lower window by fitting the midlle window to its buffer.

 > Only resizing at the cost of the upper window was allowed because it
 > has a common parent when `window-combination-limit' is t.  Now it seems
 > it has no effect and `fit-window-to-buffer' ignores the fact that
 > windows were split with `window-combination-limit' is t.

Setting `window-combination-limit' had and has only one effect in this
regard - that resizing a window _preferably_ resizes that window's buddy
first.  But if this is not sufficient, any other window can get resized.
Try to do some random splitting with `window-combination-limit' t and
then do M-x `maximize-window' for any version starting with 24.1.

 > The problem is that it steals space when the upper window is large

... I suppose you mean "when the upper window is small" here ...

 > and the *Marked files* buffer is large.  But it can't be completely
 > displayed anyway, so there is no need to resize the lower window.

IIUC `fit-window-to-buffer' always tried to display as much as possible
within limits imposed, for example, by `temp-buffer-max-height'.  Can
you tell me when and where it restricted itself to just some area of the
frame?

 > I'm not asking anything special.  I just believe that I found a bug in
 > `fit-window-to-buffer' and `window-combination-limit'.  Some time ago
 > `fit-window-to-buffer' obeyed the value t of `window-combination-limit',
 > and I don't understand why it's different now.

Please point me to any version where you saw that.  Maybe I'm missing
something.

Obviously all I say here does not preclude that we inhibit resizing any
other but the buddy window in `fit-window-to-buffer'.  But we have to
agree on such a restriction first.

martin