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

[martin rudalics]

> [ "yours truly" means something like "myself" rather than "you". ]

I must be suffering from a persecution complex.

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

That's what I meant.  Currently these issues are conflated.

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

I suppose you mean 'same-window as possible value of NOT-THIS-WINDOW
here.  Overriding the values of customized variables is problematic.
Consider the (let ((window-min-height 1)) paradigm to make a one-line
window.  This is, inherently, disastrous because it implicitly lets the
window that shall be split shrink to one line while the binding is
effective although the clear intention of the programmer is to make this
affect only the window that shall be created.

I think that an application should never bind any variable guarding the
windows popup and resizing behavior.  For `display-buffer' this means
that the entire necessary information should be passed via the
NOT-THIS-WINDOW and FRAME arguments.  For `split-window' I suppose an
explicit size argument should allow to set the size of the respective
(old or new) window disregarding the actual `window-min-height' settings
and honor these settings for all other windows.

martin