emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Monnier
Subject: Re: display-buffer-other-frame - useful? doc string?
Date: Mon, 07 Apr 2008 12:01:26 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]