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

[Stefan Monnier]

>>>>> "martin" == martin rudalics <rudalics@gmx.at> writes:

>>> Currently, OTHER-WINDOW non-nil is an application-provided setting
>> 
>> Right, and it will stay this way.
>> 
>>> and takes precedence over user customizations.
>> 
>> We would want to change that, then.
>> 
>> Note that the only customization it can override is the `same-window'
>> one IIUC, which is pretty new, so it currently only overrides user
>> customizations in very rare cases and I'm not sure that it's a feature
>> rather than a bug.

> Should `switch-to-buffer-other-window' then be allowed to display the
> buffer in the same window?  The Elisp manual would certainly forbid such
> behavior:

>      The currently selected window is absolutely never used to do the
>      job.  If it is the only window, then it is split to make a
>      distinct window for this purpose.  If the selected window is
>      already displaying the buffer, then it continues to do so, but
>      another window is nonetheless found to display it in as well.

> And the OTHER-WINDOW argument was invented precisely to handle
> `switch-to-buffer-other-window' via `display-buffer', IIUC.

I guess that depends on why switch-to-buffer-other-window uses
pop-to-buffer.

Note that the use of pop-to-buffer already causes the curent behavior to
be different from the doc you cite: with pop-up-frames set to non-nil,
if the currently selected window is the only window, it is not split:
another frame is creqated instead.


        Stefan