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

[Stefan Monnier <monnier@iro.umontreal.ca>]

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