GNU bug report logs - #1806
dired-pop-to-buffer in wrong place

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Juri Linkov <juri <at> jurta.org>, 1806 <at> debbugs.gnu.org
Subject: bug#1806: dired-pop-to-buffer in wrong place
Date: Mon, 19 Oct 2009 14:35:22 -0400

>>>>> "martin" == martin rudalics <rudalics <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.