Re: switch-to-buffer-other-frame fails to pop-up window

[Mark T. Kennedy]

interesting that you've weighed in.  i read a lot of your code while converting 
my .emacs from v21
to v22.  you've certainly confronted the buffer/window/frame style question in 
depth.  and i'm
happily using many of your libraries.

Drew Adams wrote:
>> that would certainly provide a work-around and make me happy.
>>
>> but i'm still curious why the intent of pop-up-frames is overridden by
>> display-buffer.  there has to be a reason lurking somewhere?
> 
> I like the way it works. The use case is that what one is after is for the
> buffer to be displayed - that's all. I use non-nil `pop-up-frames' to have
> `display-buffer' show a buffer for the first time in a new frame, but not to
> always show a buffer in a new frame. That's what `pop-up-frames' is about.

i'm not saying that use case isn't valid.  i'm saying there is a clash
between the word "other" in "switch-to-buffer-other-frame" and that use
case.  there is no "other" frame in the example martin gave and the use
case you prefer.  and i'm supporting my case by drawing an analogy to
the behavior of "c-x 4 b" where two windows are *always* involved.

> 
> BTW, this is not `display-buffer' _overriding_ `pop-up-frames'; the latter
> is made for the former. `pop-up-frames' has no meaning other than for
> `display-buffer'.
> 
> The relevant doc is the doc string of `display-buffer'. The doc string of
> `pop-up-frames' tries to take the shortcut of referring to `display-buffer',
> but it should be clearer about what happens if the buffer is already shown
> in a frame somewhere. The doc string of `display-buffer' is clear about
> this:
> 
>  "If `pop-up-frames' is non-nil, make a new frame
>   if no window shows BUFFER."
> 
> It is the last bit of the logic ("if no window shows BUFFER") that is
> missing from the doc string of `pop-up-frames'.

understood.

> 
> In principle, we could add a new `force' value for `pop-up-frames'. But
> there is  existing code that tests `pop-up-frames' and assumes the current
> behavior. In some cases, it uses `pop-up-frames' as a guide to user
> intentions and practice wrt frames in general. At least some of that code
> would likely need to be revisited, to see if the test is still sufficient or
> should be changed to test non-nil and non-`force'.
> 
> 

you better than anyone should have a feel for the right thing to do.
from what i can tell from a pass through the emacsWiki, you're the
buffer/window/frame usage style guru.

i tend to keep one file (buffer) per frame. i like to have help & grep & apropos
and similar things pop up and down within the frame from which they were 
invoked.
but i like "info" and "*Messages*" to be in separate, dedicated frames.  i also
find it convenient to have more than one top-level "info" frame.

what got me started down this entire path was an attempt at providing
per-frame help buffers.  i was annoyed when an existing help window
in frame X changed to the help response i generated when i invoked help
in frame Y.  i tried to take over 'help-buffer' from help-mode.el in order
to hide a per-frame help buffer name in a frame property.  but i
found that '(selected-frame)' returned the minibuffer frame when 'help-buffer' 
was
invoked rather than the frame from which "help" was invoked (i sent in a 
separate
bug report for that but haven't heard anything about it yet).

/mark


This communication and any attachments may contain confidential/proprietary 
information and is intended for information purposes only. It is not an 
invitation or offer to purchase interests from Diamondback.  Any representation 
to the contrary is unintentional.  This communication is intended only for the 
person(s) to whom it is addressed.  If you are not the intended recipient you 
are hereby notified that you have received this document in error and that any 
review, dissemination, distribution, or copying of this message or any 
attachments is not permitted.  If you have received this in error, please 
notify the sender immediately by e-mail and delete this message.  All e-mails 
sent to or received from this address will be received by Diamondback's company 
e-mail system and is subject to archival and possible review by someone other 
than the recipient.  This notice is automatically appended to each e-mail 
message leaving Diamondback.