bug#3397: NS: modeline shows inactive frame after make-frame

bug#3397: NS: modeline shows inactive frame after make-frame

[David Reitter]

When after-make-frame-functions is set to nil (which is should be by  
default),
after a (make-frame), the new frame is selected but the mode-line in  
its window shows it as unselected, even though it is selected.


after-make-frame-functions defaults to (select-frame) [ns-win.el] in  
order to work around this bug.

bug#3397: NS: modeline shows inactive frame after make-frame

[Adrian Robert]

The docs for make-frame say:

> This function itself does not make the new frame the selected frame.
> The previously selected frame remains selected.  However, the
> window system may select the new frame for its own reasons, for
> instance if the frame appears under the mouse pointer and your
> setup is for focus to follow the pointer.

How does this work under X with click-to-focus?  Or W32?

If these just leave the frame unselected, perhaps we should too,  
though it seems disturbing to users.

bug#3397: NS: modeline shows inactive frame after make-frame

[Alan Third]

Adrian Robert <adrian.b.robert@gmail.com> writes:

> The docs for make-frame say:
>
>> This function itself does not make the new frame the selected frame.
>> The previously selected frame remains selected.  However, the
>> window system may select the new frame for its own reasons, for
>> instance if the frame appears under the mouse pointer and your
>> setup is for focus to follow the pointer.
>
> How does this work under X with click-to-focus?  Or W32?
>
> If these just leave the frame unselected, perhaps we should too,
> though it seems disturbing to users.

I just checked a GTK+ build and it selects the frame even when
after-make-frame-functions is set to nil, so I'd guess that the NS build
should probably do so too.

-- 
Alan Third

bug#3397: NS: modeline shows inactive frame after make-frame

[Alan Third]

Alan Third <alan@idiocy.org> writes:

> Adrian Robert <adrian.b.robert@gmail.com> writes:
>
>> The docs for make-frame say:
>>
>>> This function itself does not make the new frame the selected frame.
>>> The previously selected frame remains selected.  However, the
>>> window system may select the new frame for its own reasons, for
>>> instance if the frame appears under the mouse pointer and your
>>> setup is for focus to follow the pointer.
>>
>> How does this work under X with click-to-focus?  Or W32?
>>
>> If these just leave the frame unselected, perhaps we should too,
>> though it seems disturbing to users.
>
> I just checked a GTK+ build and it selects the frame even when
> after-make-frame-functions is set to nil, so I'd guess that the NS build
> should probably do so too.

I've just realised this is the same problem as bug#47731.

Basically the NS port only creates emacs events within the NS run loop.
Emacs lisp runs outside the NS run loop, so when some GUI action is
called from lisp, by the time it gets down to windowDidBecomeKey or
whatever it checks whether it can create an event and the answer is no,
so it doesn't bother.

In this case that means it doesn't create the FOCUS_IN_EVENT for Emacs
and so Emacs doesn't set focus on the new frame.

I've no idea why this limitation is in place.
-- 
Alan Third