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

[martin rudalics]

>> Renaming the function is trivial.  The problem is finding meaningful
>> additional "frame-parameters" like 'same-window and 'same-frame
>
> As mentioned in some past thread, `same-frame' and `same-window'
> parameters were misdesigned (by yours truly).  It should probably be
> a single parameter with values `same-frame' or `same-window' instead.

IIRC all I did was replace "(same-buffer . t)" with "(same-window . t)"
when the buffer was supposed to be displayed in the "same" that is
"selected" window.  Using a term like "same-buffer" didn't strike me as
very intuitive and the term "same-window" was already used with similar
semantics in the "same-window-..." variables.  Moreover I tried to fix
the customization type of `special-display-buffer-names' which IIRC
didn't work before.  Is it that what you mean by "misdesign"?

Anyway, the "FRAME-PARAMETERS are pairs of the form (PARAMETER . VALUE)"
paradigm was present in Emacs 22 so I conjecture that any such misdesign
happened before I touched this ;-)

> Then we'd want to add the values `near-minibuffer' or `contiguous' for
> the dired-pop-to-buffer behavior.  For the split-orientation, I'm not
> sure if that same parameter should be used, or if a new one should be
> used instead.

I have no opinion about that because I don't use it.  But I'm afraid
that some confusion might result from the fact that "same-window" or
"near-minibuffer" could refer to the "window that shall be split" or to
the "window that shall be used" to display the buffer.

>> and how to make them interact with `pop-up-windows' and
>> `pop-up-frames'.
>
> I don't see much difficulty here.

I do.  `pop-up-windows' and `pop-up-frames' are user preferences that
should be observed.  The idea that applications can override them in
various ways - other-window > same-window > pop-up-windows is one of
these implicit priority chains `display-buffer' has to resolve - is
already not very helpful in this regard.  Giving an application even
more control wrt the behavior of `display-buffer' defeats the purpose of
customizing variables like `pop-up-windows'.

>> I'm afraid there are few people with non-nil
>> `special-display-buffer-names' already.  Making this more complicated
>> won't help anyone.
>
> I don't follow.

I suppose the only person who ever sets `special-display-buffer-names'
to a non-nil value is you.  Application programmers OTOH got used to
sweeping blows like

  (let ((special-display-buffer-names nil)
        (special-display-regexps nil)
        (same-window-buffer-names nil)
        (same-window-regexps nil))
    (pop-to-buffer ...

in order to redeem any complications caused by these variables.

So if we want users to customize these variables and at the same time
application programmers respect users' settings we should rather try to
simplify things instead of introducing further dependencies (IMHO).

martin