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

[Stefan Monnier]

> IIUC the OTHER-WINDOW argument of `pop-to-buffer' was introduced to
> allow `switch-to-buffer-other-window/-frame' use `pop-to-buffer'.

I understand.  But I also pointed out some changes in semantics (in
switch-to-buffer-other-window) that resulted from this choice that might
not have been wanted.

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

Maybe that would be a way to go.  In any case my suggestion to extend
the `other-window' arg to allow other specifications such as
same-window, same-frame, etc... was not meant to replace the current
functionality but to add some, so that more code can say what it means
rather than having to hack around (e.g. using switch-to-buffer where all
it really means is "use the current-window if possible and not specified
otherwise by the user").

>> 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 :-(

Not all of them are important, luckily,


        Stefan