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

[Mark T. Kennedy]

rms pointed out that the object returned by 'selected-frame' was the correct 
frame object.  but the
lisp printer incorrectly described it with the string "Minibuffer"-blah.  so my
one-help-buffer-per-frame hack does work.

/mark

Mark T. Kennedy wrote:
> Drew Adams wrote:
>> Not everyone agrees with my conclusions or preferences in this regard, of
>> course. But I'm glad you find some of the code useful.
>>
>> I understood. Yes, C-x 5 b behaves like C-x 4 b when the buffer is displayed
>> in a single, split frame. C-x 5 b does not create a new frame in that case,
>> so, yes, its meaning of "other frame" is not exactly analogous to C-x 4 b's
>> notion of "other window".
>>
>> No, not at all. Perhaps, however, I complain more than some about Emacs's
>> treatment of frames vs windows.
>>
>> There are others who also typically use frames instead of windows but do so
>> in a different way than I. And they don't necessarily use non-nil
>> `pop-up-frames'. Stefan Monnier is one who uses frames a bit differently - I
>> think he more or less makes each window dedicated (automatically).
>>
>> Some people always use a separate frame for each buffer, not just the first
>> time a buffer is displayed (as I do). That is, they never reuse a frame for
>> a different buffer or split its window to show more than one buffer.
>>
>> Some people who prefer frames don't use a standalone minibuffer (I do).
>>
>> Some people (including me) want deletion of a buffer or window in a
>> one-window frame to also delete the frame. Some prefer the frame to be
>> iconified. Others prefer that a different buffer fill the frame.
>>
> 
> i guess it boils down to whether you see frames and windows as
> orthogonal or hierarchical concepts.  if you see them as orthogonal,
> then you want "c-x 5 b" to always make sure there is a second frame.
> if you see them has hierarchical, then you want to see nested "green"
> behavior: first look for an existing second window, then for an
> existing second frame, and only failing both, create a new frame.
> 
>> There are thus different use cases and preferences. It's unfortunate that
>> Emacs doesn't, in general, play too well with frames, but that's the way it
>> is, so far. I think we'll eventually get it to satisfy everyone out of the
>> box (modulo Customize), but it might take some time. Martin R. has been
>> trying to fix some of the problems with quitting View mode and Help mode,
>> for instance. Some of the code is complex, and it's not always obvious how
>> to satisfy everyone.
>>
> 
> do you think it is worth while to catalog the styles of use?  as a prelude to
> finding a way to better support them?
> 
>> You might want to handle those preference differences using special-display
>> for some buffers. I do something similar for *Completions* and *Help* (in
>> library oneonone.el).
>>
>> I just clone the current Info buffer whenever I want another copy of Info:
>> `M-x clone-buffer'.
>>
> 
> i found that when i hunted through the source.  i call:
> 
> (defun my-info (node)
>   (let ((info-buffer (get-buffer "*info*")))
>     (if info-buffer
>       (progn
>         (set-buffer info-buffer)
>         (let ((new-info-buffer (clone-buffer nil t)))
>           (switch-to-buffer-other-frame new-info-buffer)
>           (info node new-info-buffer)))
>       (info node))))
> 
> from a bash shell function called "info" via emacsclient in order to
> get that behavior.  seems to work right.
> 
>> You don't want *Help* in its own frame; you want it to always open in the
>> current frame. Is that right? That's what happens by default, if
>> `pop-up-frames' is nil, no?
>>
>> emacs -Q
>> C-x d ~
>> C-x 5 2
>> C-x b *scratch*
>> C-h f forward-char ; opens *Help* in the same frame as *scratch*
>> click mouse-1 on the frame with Dired, to select it
>> C-h f backward-char ; opens *Help* in the same frame as ~ (Dired)
>>
>> I see *Help* in each frame. Of course, it has the same content (description
>> of backward-char), since it's the same buffer.
>>
>> It sounds like maybe that's what you are annoyed by: that the buffer is the
>> same in the different help windows. To get around that, I think you will
>> need to do a little juggling - perhaps rename *Help* temporarily at one
>> point or the other (automatically or manually). There is no built-in notion
>> of per-frame help buffers. IIUC, this is not really a problem about frames
>> or windows: your request seems to involve having multiple help buffers, not
>> a single *Help*.
>>
>>
> 
> right - i want a separate help buffer per frame without having to
> rename it by hand.  i tried to do that by hooking help-mode.el's
> "help-buffer" function (which computes the appropriate help buffer
> name) but i could not get it to discover the containing frame object.
> 
> by the time 'help-buffer' was called, the magic minibuffer
> implementation arranged for the magic minibuffer frame (not a
> dedicated minibuffer frame like the one you use but probably a magic
> one to allow sharing of the minibuffer across different real buffer
> frames) to be the 'selected-frame'.
> 
> you can see this by doing "M-: (selected-frame)' after a fresh "emacs
> -Q" and then repeating after popping up a second frame.  once you've
> popped up a second frame, '(selected-frame)' under "M-:" always
> returns the magic minibuffer frame (which i think is a bug).
> 
> /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.