bug#26243: 25.1; `dired-pop-to-buffer' warning

[Drew Adams]

> Yes, either 'pop-to-buffer' or 'dired-mark-pop-up'.  If 'dired-mark-
> pop-up'
> doesn't suit the needs due to its narrow applicability, then a more
> general
> 'pop-to-buffer' should be used.  'dired-pop-to-buffer' was an ugly
> wrapper
> around 'pop-to-buffer' with some additions that now should be specified
> as ACTION args of 'display-buffer' (an example is in 'dired-mark-pop-
> up').
> I don't understand why Drew still uses 'dired-pop-to-buffer'.

I use `dired-pop-to-buffer' in more than one place
in my code (Dired+).  (I use a different definition
of it, but that's not really important here.  I also
use a different definition of `dired-mark-pop-up'.)

`dired-pop-to-buffer' shouldn't have been declared
"obsolete" in my opinion.  But in any case, surely
`dired-mark-pop-up' can't be used to do anything
like what it does.  (And no, `pop-to-buffer' isn't
an adequate replacement for it either.)

> some additions that now should be specified
> as ACTION args of 'display-buffer' (an example
> is in 'dired-mark-pop-up').

FWIW, we apparently disagree about whether using
`display-buffer' ACTION args is the way to do things.
We likely have different ideas about what is elegant
and what is ugly. ;-)  When a doc string resorts to
telling users things like this, I'd say we're already
veering off the elegant road:

 "use the Customization interface to add a new rule
  to `display-buffer-alist' where condition regexp is
  \"^ \\*Marked Files\\*$\", action argument symbol
  is `window-height' and its value is nil."