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

[martin rudalics]

> Than the right fix might be to change switch-to-buffer-other-window to
> not use pop-to-buffer or to use it in an even more awkward way (binding
> special-display-buffer-names to nil arounf the call and things like
> that).

IIUC the OTHER-WINDOW argument of `pop-to-buffer' was introduced to
allow `switch-to-buffer-other-window/-frame' use `pop-to-buffer'.  Not
using `pop-to-buffer' would mean we'd have to duplicate most of the code
of `display-buffer' omitting only the parts that deal with the
`same-window-...' and `special-display-...' variables.

So I think it would be easier to have `switch-to-buffer-other-window'
pass the constant 'other-window to `display-buffer' and handle that case
specially there.  In principle this means that we'd have to ignore the
`same-window-...' variables and make sure that
`special-display-function' does not return the same window.
`switch-to-buffer-other-frame' then would have to pass 'other-frame to
`display-buffer' and be handled in a similar manner.

>> Indeed.  But my point remains that I'm not sure whether switching from
>> `switch-to-buffer' or `switch-to-buffer-other-window' to `pop-to-buffer'
>> and not using the selected window in the former (or using the selected
>> window in the latter) case might cause indignations of users.
>
> I'm not sure I understand.  We're talking about changing display-buffer
> and pop-to-buffer, not switch-to-buffer (and hopefully not
> switch-to-buffer-other-window, tho it may end up being affected
> somewhat).

What I meant is that when we have `display-buffer' not let the
NOT-THIS-WINDOW argument override user customizations we'd change the
semantics of `switch-to-buffer-other-window/-frame'.  I suppose we can't
end up having these display the buffer in the same window so we somehow
have to make sure that the NOT-THIS-WINDOW/OTHER-WINDOW argument is
handled specially for these functions (if they use `display-buffer').

>> Also so because the `switch-to...' functions are frequently used by
>> Elisp code.
>
> It's a concern but not a very serious one: I already consider such uses
> as problems to be fixed.

Well, there's lots of them :-(

martin