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

[Mark T. Kennedy]

Drew Adams wrote:
>> 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.
>
> 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'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.
>
> 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".
>
>> 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.
>
> 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?

>> 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.
>
> 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 also find it convenient to have more than one top-level "info" frame.
>
> 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.

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