bug#1806: dired-pop-to-buffer in wrong place

[martin rudalics]

> 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