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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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.
[ "yours truly" means something like "myself" rather than "you". ]
[...]
> 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 ;-)

The problem is that `same-frame' should not be a PARAMETER but a VALUE.
That was the original misdesign.

>> 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.

There are indeed two questions here:
1- in which area of which frame should the buffer be created.
2- should display-buffer create a new window for it, or should it use
   an existing window.
Maybe these two issues are really orthogonal so they deserve
separate PARAMETERS.  I.e. one parameter about *where* to display the
buffer (same-frame, same-window, near-minibuffer, nearby, ...), and the
other about how to display it (reuse-window, create-new-window, or
create-new-frame).

>>> 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'.

The intention of those changes is to let more applications use
display-buffer rather than hand-crafted combinations of split-window,
switch-to-buffer and things like that, so it should only give more
control to the user, not the opposite.

> I suppose the only person who ever sets `special-display-buffer-names'
> to a non-nil value is you.

Could be, but I doubt it.

> 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.

Yes, such programming should be fixed.  Fixing requires making it
possible for the application to say what it wants in some other way
(more precise) than by rebinding those vars.  Things like `same-window'
is precisely designed for such uses.


        Stefan