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

["Drew Adams" <drew.adams@oracle.com>]

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