display-buffer-other-frame - useful? doc string?

display-buffer-other-frame - useful? doc string?

[Drew Adams]

Is the command `display-buffer-other-frame' useful as it is currently
designed? It displays a buffer in another frame, but it also lowers
that frame among all window-manager windows. Even if the buffer was
already displayed in another frame, that frame is still lowered behind
all others.
 
That hardly seems like TRT. If you ask to display a buffer, you don't
want it to be buried out of sight behind all other window-manager
windows.
 
Aside from the question of its usefulness, I wonder about its doc
string. The first line of the doc string is identical to the first
line of the doc string of `switch-to-buffer-other-frame': "Switch to
buffer BUFFER in another frame." 
 
But `display-buffer-other-frame' does *not* switch to the buffer (it
does not select it); it simply displays it (in a not-very-visible
fashion). Contrast that with the doc string of `display-buffer', whose
first line explicitly says that the buffer is not selected: "Make
BUFFER appear in some window but don't select it."
 
Command `display-buffer-other-frame' is not documented in any manual -
perhaps for good reason. It seems half-baked, to me.
 

In GNU Emacs 22.1.90.1 (i386-mingw-nt5.1.2600)
 of 2008-01-30 on PRETEST
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Ic:/gnuwin32/include'
 

Re: display-buffer-other-frame - useful? doc string?

[Stefan Monnier]

> Is the command `display-buffer-other-frame' useful as it is currently
> designed? It displays a buffer in another frame, but it also lowers
> that frame among all window-manager windows. Even if the buffer was
> already displayed in another frame, that frame is still lowered behind
> all others.
 
> That hardly seems like TRT. If you ask to display a buffer, you don't
> want it to be buried out of sight behind all other window-manager
> windows.
 
> Aside from the question of its usefulness, I wonder about its doc
> string. The first line of the doc string is identical to the first
> line of the doc string of `switch-to-buffer-other-frame': "Switch to
> buffer BUFFER in another frame." 
 
> But `display-buffer-other-frame' does *not* switch to the buffer (it
> does not select it); it simply displays it (in a not-very-visible
> fashion). Contrast that with the doc string of `display-buffer', whose
> first line explicitly says that the buffer is not selected: "Make
> BUFFER appear in some window but don't select it."
 
> Command `display-buffer-other-frame' is not documented in any manual -
> perhaps for good reason. It seems half-baked, to me.
 
It indeed looks very odd and the code has no comment to explain/justify
the funny dance it does.  My guess is that the call to `lower-frame' is
to make sure the new frame doesn't hide the current one.  And the calls
to make-frame-(in)visible may be used to try and convince the window
manager to give focus to the original frame.

AFAICT it's only used interactively via the C-x 5 C-o binding (which
I didn't know until right now), so we should be able to change its
behavior without breaking any elisp code.

The intention of this function seems to be (compared to C-x 5 b) that
the focus should stay in the original frame rather than go to the
new frame.  Of course, focus between frames is something very difficult
for Emacs to control, especially when one of the frame is
being created.

So please to try and fix the code as best as you can, and then we can
try and ask around if your patch doesn't make things worse in
other environments.

This code was apparently installed "recently":

revision 1.820
date: 2006-03-24 08:59:14 -0500;  author: rfrancoise;  state: Exp;  lines: +1 -1;
(ctl-x-5-map): Really bind C-x 5 C-o to `display-buffer-other-frame'.
----------------------------
revision 1.819
date: 2006-03-20 10:05:19 -0500;  author: rms;  state: Exp;  lines: +15 -0;
(display-buffer-other-frame): New command.
(ctl-x-4-map): Bind C-x 5 C-o to it.
----------------------------

Maybe Richard remembers where it comes from and why it looks and behaves
the way it does?


        Stefan

RE: display-buffer-other-frame - useful? doc string?

[Drew Adams]

> > Is the command `display-buffer-other-frame' useful as it is 
> > currently designed? It displays a buffer in another frame, but
> > it also lowers that frame among all window-manager windows.
> > Even if the buffer was already displayed in another frame,
> > that frame is still lowered behind all others.
>  
> > That hardly seems like TRT. If you ask to display a buffer, 
> > you don't want it to be buried out of sight behind all other
> > window-manager windows.
>  
> > Aside from the question of its usefulness, I wonder about its doc
> > string. The first line of the doc string is identical to the first
> > line of the doc string of `switch-to-buffer-other-frame': "Switch to
> > buffer BUFFER in another frame." 
>  
> > But `display-buffer-other-frame' does *not* switch to the buffer (it
> > does not select it); it simply displays it (in a not-very-visible
> > fashion). Contrast that with the doc string of `display-buffer',
> > whose first line explicitly says that the buffer is not selected:
> > "Make BUFFER appear in some window but don't select it."
>  
> > Command `display-buffer-other-frame' is not documented in 
> > any manual - perhaps for good reason. It seems half-baked, to me.
>  
> It indeed looks very odd and the code has no comment to 
> explain/justify the funny dance it does.  My guess is that the
> call to `lower-frame' is to make sure the new frame doesn't hide
> the current one.  And the calls to make-frame-(in)visible may be
> used to try and convince the window
> manager to give focus to the original frame.
> 
> AFAICT it's only used interactively via the C-x 5 C-o binding (which
> I didn't know until right now), so we should be able to change its
> behavior without breaking any elisp code.
> 
> The intention of this function seems to be (compared to C-x 5 b) that
> the focus should stay in the original frame rather than go to the
> new frame.  Of course, focus between frames is something very 
> difficult for Emacs to control, especially when one of the frame is
> being created.

I agree with everything you said. However, I don't see that such a command
would be very useful. Maybe the best thing to do is to remove it altogether

> So please to try and fix the code as best as you can, and then we can
> try and ask around if your patch doesn't make things worse in
> other environments.

Well, here's all I would do, if I wanted such a command:

(defun display-buffer-other-frame (buffer)
  "Show BUFFER in another frame, but don't select it.
See documentation of `display-buffer' for more information."
  (interactive "BDisplay buffer in other frame: ")
  (let ((win (selected-window)))
    (switch-to-buffer-other-frame buffer)
    (select-window win)
    (select-frame-set-input-focus (window-frame win))))

That seems to DTRT. Do you really need a patch for that? Try it first, and
see if that's what you want.

Re: display-buffer-other-frame - useful? doc string?

[Richard Stallman]

    Is the command `display-buffer-other-frame' useful as it is currently
    designed? It displays a buffer in another frame, but it also lowers
    that frame among all window-manager windows. Even if the buffer was
    already displayed in another frame, that frame is still lowered behind
    all others.

It is certainly wrong to lower the frame.  I wonder why that happens.
Is there explicit code to do it, or is it an unwanted side effect?

RE: display-buffer-other-frame - useful? doc string?

[Drew Adams]

> It is certainly wrong to lower the frame.  I wonder why that happens.
> Is there explicit code to do it, or is it an unwanted side effect?

There is explicit code.
But see my proposed redefinition.

Re: display-buffer-other-frame - useful? doc string?

[Richard Stallman]

    It indeed looks very odd and the code has no comment to explain/justify
    the funny dance it does.  My guess is that the call to `lower-frame' is
    to make sure the new frame doesn't hide the current one.

If you take that out, does the frame get raised instead?
If so, that would be the explanation.  But the right thing isn't to lower
the frame, it is to avoid raising it.

Re: display-buffer-other-frame - useful? doc string?

[Richard Stallman]

    I agree with everything you said. However, I don't see that such a command
    would be very useful. Maybe the best thing to do is to remove it altogether

It exists just for the sake of symmetry of the command set,
since this is the natural thing for C-x 5 C-o to do.
If having it is painful, we can get rid of it.

RE: display-buffer-other-frame - useful? doc string?

[Drew Adams]

>     I agree with everything you said. However, I don't see 
>     that such a command would be very useful. Maybe the best
>     thing to do is to remove it altogether
> 
> It exists just for the sake of symmetry of the command set,
> since this is the natural thing for C-x 5 C-o to do.
> If having it is painful, we can get rid of it.

I proposed this fix. I think it DTRT.

(defun display-buffer-other-frame (buffer)
  "Show BUFFER in another frame, but don't select it.
See documentation of `display-buffer' for more information."
  (interactive "BDisplay buffer in other frame: ")
  (let ((win (selected-window)))
    (switch-to-buffer-other-frame buffer)
    (select-window win)
    (select-frame-set-input-focus (window-frame win))))

Re: display-buffer-other-frame - useful? doc string?

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> The intention of this function seems to be (compared to C-x 5 b) that
> the focus should stay in the original frame rather than go to the
> new frame.

Except that the current frame is unmapped, and thus made completely
invisible (not even iconified).  IMHO that the worst feature of that
function.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: display-buffer-other-frame - useful? doc string?

[Stefan Monnier]

>     I agree with everything you said. However, I don't see that such
>     a command would be very useful. Maybe the best thing to do is to
>     remove it altogether

> It exists just for the sake of symmetry of the command set,
> since this is the natural thing for C-x 5 C-o to do.

Symmetry?  Could you explain what you mean?
C-x C-o doesn't to be what you're referring to (it's bound to
delete-blank-lines).


        Stefan

Re: display-buffer-other-frame - useful? doc string?

[Stefan Monnier]

>> The intention of this function seems to be (compared to C-x 5 b) that
>> the focus should stay in the original frame rather than go to the
>> new frame.

> Except that the current frame is unmapped, and thus made completely
> invisible (not even iconified).  IMHO that the worst feature of that
> function.

Hmm.. the code does:

    (make-frame-invisible (window-frame old-window))
    (make-frame-visible (window-frame old-window))

so it *shouldn't* stay invisible.  Then again, given the way interaction
with window-managers is always unreliable and messed up, I wouldn't be
surprised to hear that the second call can occasionally get lost.


        Stefan

Re: display-buffer-other-frame - useful? doc string?

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> The intention of this function seems to be (compared to C-x 5 b) that
>>> the focus should stay in the original frame rather than go to the
>>> new frame.
>
>> Except that the current frame is unmapped, and thus made completely
>> invisible (not even iconified).  IMHO that the worst feature of that
>> function.
>
> Hmm.. the code does:
>
>     (make-frame-invisible (window-frame old-window))
>     (make-frame-visible (window-frame old-window))
>
> so it *shouldn't* stay invisible.

That didn't work when I tried it with fvwm2.  But in any case, it will
result in an annoying flicker.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: display-buffer-other-frame - useful? doc string?

[Richard Stallman]

    > It exists just for the sake of symmetry of the command set,
    > since this is the natural thing for C-x 5 C-o to do.

    Symmetry?  Could you explain what you mean?
    C-x C-o doesn't to be what you're referring to (it's bound to
    delete-blank-lines).

It is analogous to C-x 4 C-o.

The natural meaning of C-x C-o would be "display a buffer in the
selected window but don't select that window," which is sort of
self contradictory.  In fact, that meaning for C-x C-o is older
than C-x 4.

RE: display-buffer-other-frame - useful? doc string?

[Drew Adams]

I thought this had been fixed. CVS shows that the code and doc string are still
problematic. The only thing that was done was to comment out the silly
`lower-frame' and `make-frame(-in)-visible' dance and add a comment saying that
that was harmful and silly. (That at least stopped the frame from being
lowered.)

I sent this code (*twice*), which DTRT. It simply displays the buffer in another
frame. (If it's important, you can add null bindings for `same-window-*' and
return the selected window, as before.)

(defun display-buffer-other-frame (buffer)
  "Show BUFFER in another frame, but don't select it.
See documentation of `display-buffer' for more information."
  (interactive "BDisplay buffer in other frame: ")
  (let ((win (selected-window)))
    (switch-to-buffer-other-frame buffer)
    (select-window win)
    (select-frame-set-input-focus (window-frame win))))

That suggestion was ignored. 

At least on Windows, with the change that was made instead, the command doesn't
just display the buffer in another frame. It also selects the buffer, so it does
the same thing as `switch-to-buffer-other-frame'. Displaying a buffer is not the
same as switching to it. We don't need two different commands with two key
bindings to switch to a buffer in another frame.

On Windows, at least, frame focus changes when you display a buffer the way the
current code does. You need to explicitly set the frame focus back to the
original window, to not have it change. Perhaps there is another way - dunno.

If this command is supposed to do what its name suggests, then it is implemented
wrong, IMO. Do it a different way, if you want, but please do what the command
name says, not something else.

In any case, the doc string is (still) incorrect. The first line is still
identical to that of `switch-to-buffer-other-frame', and it still implies that
the buffer is selected (which it is, on Windows, but which is presumably not the
intention).

Why is it so hard to get such a simple correction made? A 13-mail thread, for
nada. Why just add a complex comment about the old code being brain-dead,
instead of DTRT? One of us is not getting it.

Here is the current definition:

(defun display-buffer-other-frame (buffer)
  "Switch to buffer BUFFER in another frame.
This uses the function `display-buffer' as a subroutine; see its
documentation for additional customization information."
  (interactive "BDisplay buffer in other frame: ")
  (let ((pop-up-frames t)
	  same-window-buffer-names same-window-regexps
        (old-window (selected-window))
	  new-window)
    (setq new-window (display-buffer buffer t))
    ;; This may have been here in order to prevent the new frame from hiding
    ;; the old frame.  But it does more harm than good.
    ;; Maybe we should call `raise-window' on the old-frame instead?  --Stef
    ;;(lower-frame (window-frame new-window))

    ;; This may have been here in order to make sure the old-frame gets the
    ;; focus.  But not only can it cause an annoying flicker, with some
    ;; window-managers it just makes the window invisible, with no easy
    ;; way to recover it.  --Stef
    ;;(make-frame-invisible (window-frame old-window))
    ;;(make-frame-visible (window-frame old-window))
    ))

> From: Drew Adams Sent: Sunday, March 09, 2008 11:01 AM
> Is the command `display-buffer-other-frame' useful as it is currently
> designed? It displays a buffer in another frame, but it also lowers
> that frame among all window-manager windows. Even if the buffer was
> already displayed in another frame, that frame is still lowered behind
> all others.
>  
> That hardly seems like TRT. If you ask to display a buffer, you don't
> want it to be buried out of sight behind all other window-manager
> windows.
>  
> Aside from the question of its usefulness, I wonder about its doc
> string. The first line of the doc string is identical to the first
> line of the doc string of `switch-to-buffer-other-frame': "Switch to
> buffer BUFFER in another frame." 
>  
> But `display-buffer-other-frame' does *not* switch to the buffer (it
> does not select it); it simply displays it (in a not-very-visible
> fashion). Contrast that with the doc string of `display-buffer', whose
> first line explicitly says that the buffer is not selected: "Make
> BUFFER appear in some window but don't select it."
>  
> Command `display-buffer-other-frame' is not documented in any manual -
> perhaps for good reason. It seems half-baked, to me. 

Re: display-buffer-other-frame - useful? doc string?

[Stefan Monnier]

> I thought this had been fixed.  CVS shows that the code and doc string
> are still problematic.  The only thing that was done was to comment out
> the silly `lower-frame' and `make-frame(-in)-visible' dance and add
> a comment saying that that was harmful and silly. (That at least
> stopped the frame from being lowered.)

The problem is that display-buffer doesn't work as it should.
So we should fix display-buffer.  Can you try the following:

  (lexical-let ((f pop-up-frame-function))
    (setq pop-up-frame-function
      (lambda ()
        (let ((win (selected-window)))
          (unwind-protect
              (funcall f)
            (when (window-live-p win)
              (select-window win)
              (select-frame-set-input-focus (window-frame win))))))))

If this works, can you try to inline select-frame-set-input-focus and
remove each part one by one until you figure out which part is necessary
and which part isn't.

The difficulty is that select-frame-set-input-focus doesn't do the right
thing in my situation: it raises the current frame whereas it shouldn't
be doing that.


        Stefan

RE: display-buffer-other-frame - useful? doc string?

[Drew Adams]

> The problem is that display-buffer doesn't work as it should.
> So we should fix display-buffer.  Can you try the following:
> 
>   (lexical-let ((f pop-up-frame-function))
>     (setq pop-up-frame-function
>       (lambda ()
>         (let ((win (selected-window)))
>           (unwind-protect
>               (funcall f)
>             (when (window-live-p win)
>               (select-window win)
>               (select-frame-set-input-focus (window-frame win))))))))
> 
> If this works, can you try to inline select-frame-set-input-focus and
> remove each part one by one until you figure out which part 
> is necessary and which part isn't.

Sorry, I don't understand what you would like me to do. Looking at that code, it
seems clear enough, but I don't understand what problem it is trying to solve or
what you would like me to try. In what way does display-buffer not work
correctly? What problems with dynamic binding do you see or foresee?

If I eval that code I get this: (void-function lexical-let)

OK, I found that lexical-let is in cl.el. After loading that, the code seems to
do nothing. 

I tried using it as the body of `display-buffer-other-frame', adding a call to
`display-buffer'. That too didn't work - the buffer was opened in the same
frame. I added `pop-up-frames', like this:

(defun display-buffer-other-frame (buffer)
  "Show BUFFER in another frame, but don't select it.
See documentation of `display-buffer' for more information."
  (interactive "BDisplay buffer in other frame: ")
  (lexical-let ((f pop-up-frame-function))
    (setq pop-up-frame-function
      (lambda ()
        (let ((win (selected-window)))
          (unwind-protect
              (funcall f)
            (when (window-live-p win)
              (select-window win)
              (select-frame-set-input-focus (window-frame win)))))))
    (let ((pop-up-frames t))
      (display-buffer buffer t t))))

That just did the same thing as `switch-to-buffer-other-frame': the frame was
selected.

I'm obviously not guessing what it is you want me to try. Why don't you just
give me the complete code to try?

> The difficulty is that select-frame-set-input-focus doesn't 
> do the right thing in my situation: it raises the current frame
> whereas it shouldn't be doing that.

If `select-frame-set-input-focus' doesn't work in your situation, then perhaps
that's the place to debug? It seems to DTRT here (Windows). Emacs would be
unusable for me without it, given the way I use multiple frames, including for
side operations during completion.

If you let me know more clearly what you want, I'll give it a try. But it sounds
like there is a `select-frame-set-input-focus problem' in some contexts, in
addition to trying to get `display-buffer-other-frame' well-defined.

The code I sent works fine here, AFAICT. Maybe the problem is just to fix the
`select-frame-set-input-focus' problem you see at your end?

Re: display-buffer-other-frame - useful? doc string?

[Stefan Monnier]

>> The problem is that display-buffer doesn't work as it should.
>> So we should fix display-buffer.  Can you try the following:
>> 
>> (lexical-let ((f pop-up-frame-function))
>> (setq pop-up-frame-function
>> (lambda ()
>> (let ((win (selected-window)))
>> (unwind-protect
>> (funcall f)
>> (when (window-live-p win)
>> (select-window win)
>> (select-frame-set-input-focus (window-frame win))))))))
>> 
>> If this works, can you try to inline select-frame-set-input-focus and
>> remove each part one by one until you figure out which part 
>> is necessary and which part isn't.

> Sorry, I don't understand what you would like me to do. Looking at
> that code, it seems clear enough, but I don't understand what problem
> it is trying to solve or what you would like me to try. In what way
> does display-buffer not work correctly? What problems with dynamic
> binding do you see or foresee?

If you look at it and try to understand it (knowing that display-buffer
supposedly calls pop-up-frame-function to create a new frame), you'll
see that it is trying to run the exact code you say works for your
display-buffer-other-frame.

I.e. evaluating the above code via M-: (or in your .emacs) should
hopefully make display-buffer work correctly such that the trunk's
display-buffer-other-frame works just as well as the one you've
been using.

>> The difficulty is that select-frame-set-input-focus doesn't 
>> do the right thing in my situation: it raises the current frame
>> whereas it shouldn't be doing that.

> If `select-frame-set-input-focus' doesn't work in your situation, then perhaps
> that's the place to debug?

It is documented as doing a "raise", but in the display-buffer case we
don't want to do a raise (at least not for window managers where the
window with focus should not need to be raised).  So using
select-frame-set-input-focus can't be right (unless we not only change
its code but also its spec).


        Stefan

RE: display-buffer-other-frame - useful? doc string?

[Drew Adams]

> I.e. evaluating the above code via M-: (or in your .emacs) should
> hopefully make display-buffer work correctly such that the trunk's
> display-buffer-other-frame works just as well as the one you've
> been using.

It does not. With Emacs 23, on MS Windows (emacs -Q): I evaluate only the code
snippet you sent. Then, C-x 5 C-o does what switch-to-buffer-other-frame does:
it selects the buffer; it doesn't just display it.

Perhaps someone else on Windows can try it also, to confirm, but that's what I
see.

> >> The difficulty is that select-frame-set-input-focus doesn't 
> >> do the right thing in my situation: it raises the current frame
> >> whereas it shouldn't be doing that.
> 
> > If `select-frame-set-input-focus' doesn't work in your 
> > situation, then perhaps that's the place to debug?
> 
> It is documented as doing a "raise", but in the display-buffer case we
> don't want to do a raise (at least not for window managers where the
> window with focus should not need to be raised).  So using
> select-frame-set-input-focus can't be right (unless we not only change
> its code but also its spec).

I see. Do you think that's a problem, in practice, for this particular command
(which several of us even advised tossing out)? It would make a difference only
when the window selected before the command was not in the front frame, and only
for a window mgt policy that gives a frame focus without raising it.

I'd say that the command as I implemented it (or equivalent behavior with a
different implementation) is better than nothing (and much better than what
exists today). 

If you improve the command to not also raise the selected frame, so much the
better. If not, no big deal - just clarify the behavior in the doc string wrt
raising the frame. I don't think it's a big deal.

If it's important to you that the initially selected window not have its frame
raised, then perhaps another function is needed - a function like
`select-frame-set-input-focus', but which doesn't raise the frame. Or perhaps
add an optional arg to `select-frame-set-input-focus' to express that
alternative behavior.

In any case, the current behavior is inappropriate.

Re: display-buffer-other-frame - useful? doc string?

[Stefan Monnier]

>> I.e. evaluating the above code via M-: (or in your .emacs) should
>> hopefully make display-buffer work correctly such that the trunk's
>> display-buffer-other-frame works just as well as the one you've
>> been using.

> It does not. With Emacs 23, on MS Windows (emacs -Q): I evaluate only
> the code snippet you sent. Then, C-x 5 C-o does what
> switch-to-buffer-other-frame does: it selects the buffer; it doesn't
> just display it.

Hmm... so now we need to figure out whyh my code works differently
from your.  Maybe it's just a silly bug in my code, but maybe there's
something deeper.

> Perhaps someone else on Windows can try it also, to confirm, but
> that's what I see.

I believe you.

>> >> The difficulty is that select-frame-set-input-focus doesn't 
>> >> do the right thing in my situation: it raises the current frame
>> >> whereas it shouldn't be doing that.
>> 
>> > If `select-frame-set-input-focus' doesn't work in your 
>> > situation, then perhaps that's the place to debug?
>> 
>> It is documented as doing a "raise", but in the display-buffer case we
>> don't want to do a raise (at least not for window managers where the
>> window with focus should not need to be raised).  So using
>> select-frame-set-input-focus can't be right (unless we not only change
>> its code but also its spec).

> I see. Do you think that's a problem, in practice, for this particular
> command (which several of us even advised tossing out)?

I'm talking here about fixing display-buffer not just
display-buffer-other-frame.

> If it's important to you that the initially selected window not have its frame
> raised, then perhaps another function is needed - a function like
> `select-frame-set-input-focus', but which doesn't raise the frame. Or perhaps
> add an optional arg to `select-frame-set-input-focus' to express that
> alternative behavior.

Maybe, maybe not: maybe the raise is the part that makes it work.
That's what I'm trying to figure out.


        Stefan

RE: display-buffer-other-frame - useful? doc string?

[Drew Adams]

> Hmm... so now we need to figure out whyh my code works differently
> from your.  Maybe it's just a silly bug in my code, but maybe there's
> something deeper.
> 
> > Perhaps someone else on Windows can try it also, to confirm, but
> > that's what I see.
> 
> I believe you.

I believe me too, but I can make mistakes. It would be good if someone would
confirm this behavior on Windows, before we try to fix problems that might not
exist.

> > I see. Do you think that's a problem, in practice, for this 
> > particular command (which several of us even advised tossing out)?
> 
> I'm talking here about fixing display-buffer not just
> display-buffer-other-frame.

Oh, right.

> > If it's important to you that the initially selected window 
> > not have its frame raised, then perhaps another function is
> > needed - a function like `select-frame-set-input-focus',
> > but which doesn't raise the frame. Or perhaps
> > add an optional arg to `select-frame-set-input-focus' to 
> > express that alternative behavior.
> 
> Maybe, maybe not: maybe the raise is the part that makes it work.
> That's what I'm trying to figure out.

Ah, yes, that's possible.

Re: display-buffer-other-frame - useful? doc string?

[Lennart Borgman (gmail)]

Drew Adams wrote:
>> Hmm... so now we need to figure out whyh my code works differently
>> from your.  Maybe it's just a silly bug in my code, but maybe there's
>> something deeper.
>>
>>> Perhaps someone else on Windows can try it also, to confirm, but
>>> that's what I see.
>> I believe you.
> 
> I believe me too, but I can make mistakes. It would be good if someone would
> confirm this behavior on Windows, before we try to fix problems that might not
> exist.


Can you give us some code to test?

RE: display-buffer-other-frame - useful? doc string?

[Drew Adams]

> Can you give us some code to test?

Stefan's code. Load cl.el, then eval this:

(lexical-let ((f pop-up-frame-function))
    (setq pop-up-frame-function
      (lambda ()
        (let ((win (selected-window)))
          (unwind-protect
              (funcall f)
            (when (window-live-p win)
              (select-window win)
              (select-frame-set-input-focus (window-frame win))))))))

Then try `C-x 5 C-o' (`display-buffer-other-frame'). 

If the code works, it should make `display-buffer' (and so
`display-buffer-other-frame') use the redefined `pop-up-frame-function', which
should display the buffer without selecting it.

What I see instead is that the displayed buffer gets selected - its frame gets
the focus, which is not the intention.

Re: display-buffer-other-frame - useful? doc string?

[Lennart Borgman (gmail)]

Drew Adams wrote:
>> Can you give us some code to test?
> 
> Stefan's code. Load cl.el, then eval this:
> 
> (lexical-let ((f pop-up-frame-function))
>     (setq pop-up-frame-function
>       (lambda ()
>         (let ((win (selected-window)))
>           (unwind-protect
>               (funcall f)
>             (when (window-live-p win)
>               (select-window win)
>               (select-frame-set-input-focus (window-frame win))))))))
> 
> Then try `C-x 5 C-o' (`display-buffer-other-frame'). 
> 
> If the code works, it should make `display-buffer' (and so
> `display-buffer-other-frame') use the redefined `pop-up-frame-function', which
> should display the buffer without selecting it.
> 
> What I see instead is that the displayed buffer gets selected - its frame gets
> the focus, which is not the intention.


Yes, that is what I also see.

GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-04-06

RE: display-buffer-other-frame - useful? doc string?

[Drew Adams]

> > What I see instead is that the displayed buffer gets 
> > selected - its frame gets
> > the focus, which is not the intention.
> 
> Yes, that is what I also see.

Thanks for checking.