>>> The problem is that it steals space when the upper window is large
 >> ... I suppose you mean "when the upper window is small" here ...
 >
 > When a window has 30 lines in height, I call it "large" :-)

So splitting a 30 lines window is not enough for getting you enough
space for the Marked Files buffer.  How many lines would you need?

 >> 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'll try to provide the exact details:
 >
 > 1. When the Dired window is small (less than 7 lines in height),
 >    there is no problem because it reuses the lower window.

Because `window--try-to-split-window' fails immediately, I presume.

 > 2. When the Dired window is large (more than 7 lines in height)
 >    and a list of marked files is small:
 >
 > 2.1. When `window-combination-limit' is nil,
 >      the result of `dired-mark-pop-up' is horribly ugly
 >      (when `temp-buffer-resize-mode' is enabled).  But thank you
 >      `window-combination-limit' is not nil anymore,
 >      so there is no problem now.

What you probably intend to say between these lines is that users should
not have to enable `temp-buffer-resize-mode' to avoid that horribly ugly
result.

 > 2.2. When `window-combination-limit' is non-nil, the result is still
 >      bad looking because `fit-window-to-buffer' is missing like in the
 >      original version of `dired-pop-to-buffer'.  This is a regression.

This is the part I don't understand.  Suppose with Emacs -Q I do

C-x 2
(setq window-combination-limit t)
(temp-buffer-resize-mode 1)
C-x d

for some directory, mark some files and type D, the space for the
*Deletions* window is taken from the upper window only.

 > 2.3. When a list of files is too large to fit into split windows, it
 >      resizes the lower window.  What I misremembered is that actually it
 >      never tried to avoid resizing the lower window.  Sorry for my amnesia.
 >      This is not a regression.  Its result looks like when
 >      `window-combination-limit' is nil, but since a large list of files
 >      is rarely displayed in Dired, this is a minor problem.

We agree here.

 > So the main problem that remains is the need to use `fit-window-to-buffer'.

I suppose you intend "the need to enable `temp-buffer-resize-mode'"
here.  `fit-window-to-buffer' has been used all the time.

 > I see three possible variants to fix this:
 >
 > 1. Call `fit-window-to-buffer' directly in `dired-mark-pop-up'.

This solves the problem at hand but is no general fix.  In addition we'd
have to maintain things like `dired-shrink-to-fit' forever.

 > 2. Call `fit-window-to-buffer' in `display-buffer-below-selected'
 >    using a new action specifier.

This is still not a complete solution since `fit-window-to-buffer'
should apply whenever we create a new window.

 > 3. Enable `temp-buffer-resize-mode'.

 From your and Chong less than enthusiastic comments this is no good.

I think your idea to pass an appropriate alist entry to `display-buffer'
was best.  I attach a patch which should do that, in principle (actually
I just revived the respective part from my old specifiers approach).

Anyone who wants the nil behavior for `dired-shrink-to-fit' can add a
corresponding entry to `display-buffer-alist' as you proposed earlier.
(Someone would have to formulate that for users nicely and in the
appropriate context.)

The resizing request by `temp-buffer-resize-mode' is still done
explicitly in the corresponding hook but this can be moved to
`display-buffer' in a similar fashion.  Unless we decide that
`temp-buffer-resize-mode' should be removed, that is, moved to
`display-buffer-alist'.

martin