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

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

[Mark T. Kennedy]

recipe:

1) start emacs with "-Q"
2) type "c-x b foo", then "c-x 2", and then "c-x b".
   now "*scratch* and "foo" are displayed in two windows
   on the original single frame.
3) now type "c-x 5 b foo" and see that a new frame is not
   popped up.

contrast this with "emacs -Q" and "c-x 4 b foo" followed by
"c-x 5 b foo".

/mark kennedy

In GNU Emacs 22.1.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.8.18)
 of 2007-11-09 on d1.diamondbackcap.corp
Windowing system distributor `The X.Org Foundation', version 11.0.70000000
configured using `configure  '--with-gtk' 'CFLAGS=-g''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
<help-echo> <escape> x s e n d - b u <tab> <backspace>
<backspace> <tab> <backspace> <backspace> <backspace>
<backspace> <backspace> b u g <tab> <backspace> <backspace>
<backspace> r e <tab> p o r <tab> <return>

Recent messages:
("emacs" "-Q")
For information about the GNU Project and its goals, type C-h C-p.
Making completion list...
Loading help-mode...done
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done

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 a
 rchival and possible review by someone other than the recipient.  This notice is automatically appended to each e-mail message leaving Diamondback.

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

[martin rudalics]

 > 1) start emacs with "-Q"
 > 2) type "c-x b foo", then "c-x 2", and then "c-x b".
 >    now "*scratch* and "foo" are displayed in two windows
 >    on the original single frame.

At this moment the window displaying "foo" is _not_ selected.

 > 3) now type "c-x 5 b foo" and see that a new frame is not
 >    popped up.

But the window displaying "foo" should be selected now.  This is the
expected behavior of `display-buffer' which is mentioned in the
doc-string of `switch-to-buffer-other-frame'.

Maybe `switch-to-buffer-other-frame' should _always_ display the buffer
in another frame - that is call `display-buffer-other-frame' and select
that frame (C-x 5 C-o doesn't _select_ the other frame).

 > contrast this with "emacs -Q" and "c-x 4 b foo" followed by
 > "c-x 5 b foo".

Because at the time you invoke C-x 5 b foo here a window showing "foo"
is selected.  Again this is the documented behavior of `display-buffer'.

Just some explanations - feel free to demand a more intuitive behavior
and/or description.  To me it's not entirely clear how to reconcile all
possible use cases.

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

[Mark T. Kennedy]

two observations:

1) contrast the behavior of 'c-x 5 b' with 'c-x 4 b'.  'c-x 4 b' always forces the creation of two
different windows, even when displaying the same buffer.  'c-x 5 b' does not always force the
creation of two frames.

2) one might guess that 'switch-to-buffer-other-frame' is essentially a wrapper that
sets 'pop-up-frames' to 't' and then calls display-buffer (and it is).
while the behavior of display-buffer is meticulously documented, the observed
behavior clashes with the documentation for 'pop-up-frames'.  now if it were
called "maybe-pop-up-frames" or "frequently-pop-up-frames", i wouldn't feel
so bad, but... :-).

so i'm requesting (not demanding :-) a change in behavior.

what use case would clash with a change like this?

/mark

martin rudalics wrote:
>  > 1) start emacs with "-Q"
>  > 2) type "c-x b foo", then "c-x 2", and then "c-x b".
>  >    now "*scratch* and "foo" are displayed in two windows
>  >    on the original single frame.
> 
> At this moment the window displaying "foo" is _not_ selected.
> 
>  > 3) now type "c-x 5 b foo" and see that a new frame is not
>  >    popped up.
> 
> But the window displaying "foo" should be selected now.  This is the
> expected behavior of `display-buffer' which is mentioned in the
> doc-string of `switch-to-buffer-other-frame'.
> 
> Maybe `switch-to-buffer-other-frame' should _always_ display the buffer
> in another frame - that is call `display-buffer-other-frame' and select
> that frame (C-x 5 C-o doesn't _select_ the other frame).
> 
>  > contrast this with "emacs -Q" and "c-x 4 b foo" followed by
>  > "c-x 5 b foo".
> 
> Because at the time you invoke C-x 5 b foo here a window showing "foo"
> is selected.  Again this is the documented behavior of `display-buffer'.
> 
> Just some explanations - feel free to demand a more intuitive behavior
> and/or description.  To me it's not entirely clear how to reconcile all
> possible use cases.
> 
> 

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 a
 rchival and possible review by someone other than the recipient.  This notice is automatically appended to each e-mail message leaving Diamondback.

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

[martin rudalics]

 > 1) contrast the behavior of 'c-x 5 b' with 'c-x 4 b'.  'c-x 4 b' always forces the creation of two
 > different windows, even when displaying the same buffer.  'c-x 5 b' does not always force the
 > creation of two frames.

When you have two windows on the selected frame, w1 is the selected
window and w2 the other one, w2 shows buffer b, and w1 does not show
buffer b, C-x 4 b will simply switch to w2.  Thus C-x 4 b and C-x 5 b
behave very similarly.

 > 2) one might guess that 'switch-to-buffer-other-frame' is essentially a wrapper that
 > sets 'pop-up-frames' to 't' and then calls display-buffer (and it is).
 > while the behavior of display-buffer is meticulously documented, the observed
 > behavior clashes with the documentation for 'pop-up-frames'.  now if it were
 > called "maybe-pop-up-frames" or "frequently-pop-up-frames", i wouldn't feel
 > so bad, but... :-).

The documentation of `pop-up-frames' in the Elisp manual appears
correct:

  -- User Option: pop-up-frames
      This variable controls whether `display-buffer' makes new frames.
      If it is non-`nil', `display-buffer' looks for an existing window
      already displaying the desired buffer, on any visible frame.  If
      it finds one, it returns that window.  Otherwise it makes a new
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      frame.  The variables `pop-up-windows' and
      `split-height-threshold' do not matter if `pop-up-frames' is
      non-`nil'.

The doc-strings of `pop-up-frames' and `switch-to-buffer-other-frame'
are misleading.  The former says "*Non-nil means `display-buffer' should
make a separate frame." but fails to explain the semantics of "should".
The latter tells "Switch to buffer buffer in another frame." which is
just silly IMHO.

 > so i'm requesting (not demanding :-) a change in behavior.
 >
 > what use case would clash with a change like this?

I don't know, maybe there is one.  We could try to provide a third value
for `pop-up-frames': If it's 'force `display-buffer' would _always_ try
to display the buffer in a new frame regardless of how many times it is
already displayed.  What do you think?

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

[Mark T. Kennedy]

martin rudalics wrote:
>  > 1) contrast the behavior of 'c-x 5 b' with 'c-x 4 b'.  'c-x 4 b' always forces the creation of two
>  > different windows, even when displaying the same buffer.  'c-x 5 b' does not always force the
>  > creation of two frames.
>
> When you have two windows on the selected frame, w1 is the selected
> window and w2 the other one, w2 shows buffer b, and w1 does not show
> buffer b, C-x 4 b will simply switch to w2.  Thus C-x 4 b and C-x 5 b
> behave very similarly.

but two windows exist already in your "c-x 4 b" scenario.  and if only one window
existed, it would be created.  the "other window" invariant is maintained regardless
of whether it has to create a new window or just switch to an existing one.

but "c-x 5 b" behaves like "c-x 4 b" in the single-frame, two-window
scenario you described above.  it does *not* cause a second frame to
be created.  it just switches to w2 without creating a new frame.  the
"other frame" invariant is *not* maintained.

>
>  > 2) one might guess that 'switch-to-buffer-other-frame' is essentially a wrapper that
>  > sets 'pop-up-frames' to 't' and then calls display-buffer (and it is).
>  > while the behavior of display-buffer is meticulously documented, the observed
>  > behavior clashes with the documentation for 'pop-up-frames'.  now if it were
>  > called "maybe-pop-up-frames" or "frequently-pop-up-frames", i wouldn't feel
>  > so bad, but... :-).
>
> The documentation of `pop-up-frames' in the Elisp manual appears
> correct:
>
>   -- User Option: pop-up-frames
>       This variable controls whether `display-buffer' makes new frames.
>       If it is non-`nil', `display-buffer' looks for an existing window
>       already displaying the desired buffer, on any visible frame.  If
>       it finds one, it returns that window.  Otherwise it makes a new
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>       frame.  The variables `pop-up-windows' and
>       `split-height-threshold' do not matter if `pop-up-frames' is
>       non-`nil'.
>
> The doc-strings of `pop-up-frames' and `switch-to-buffer-other-frame'
> are misleading.  The former says "*Non-nil means `display-buffer' should
> make a separate frame." but fails to explain the semantics of "should".
> The latter tells "Switch to buffer buffer in another frame." which is
> just silly IMHO.

mea culpa.  i did not think to look in the elisp doc.

>
>  > so i'm requesting (not demanding :-) a change in behavior.
>  >
>  > what use case would clash with a change like this?
>
> I don't know, maybe there is one.  We could try to provide a third value
> for `pop-up-frames': If it's 'force `display-buffer' would _always_ try
> to display the buffer in a new frame regardless of how many times it is
> already displayed.  What do you think?
>
>

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?

/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 a
 rchival and possible review by someone other than the recipient.  This notice is automatically appended to each e-mail message leaving Diamondback.

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

[Drew Adams]

> >  > what use case would clash with a change like this?
> >
> > I don't know, maybe there is one.  We could try to provide a third value
> > for `pop-up-frames': If it's 'force `display-buffer' would _always_ try
> > to display the buffer in a new frame regardless of how many times it is
> > already displayed.  What do you think?
>
> 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.

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

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

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 a
 rchival and possible review by someone other than the recipient.  This notice is automatically appended to each e-mail message leaving Diamondback.

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

[Drew Adams]

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

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.

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

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

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 a
 rchival and possible review by someone other than the recipient.  This notice is automatically appended to each e-mail message leaving Diamondback.

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

[Drew Adams]

> > There are thus different use cases and preferences.
>
> 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 wouldn't try, but that's sort of what happens anyway, little by little.
When someone such as Martin tries to fix a reported bug, he tries to
understand the reported use case and accomodate it appropriately.

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

No, if I understand you correctly, that is normal. During `M-:', the
minibuffer must have the input focus, so its frame is selected.

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 a
 rchival and possible review by someone other than the recipient.  This notice is automatically appended to each e-mail message leaving Diamondback.