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

Previous Next

To reply to this bug, email your comments to 3397 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: emacs-pretest-bug <at> gnu.org
Subject: NS: modeline shows inactive frame after make-frame
Date: Tue, 26 May 2009 21:42:51 -0400

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.

Message #12 received at 3397 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: 3397 <at> debbugs.gnu.org
Subject: Re: NS: modeline shows inactive frame after make-frame
Date: Thu, 23 Jul 2009 12:34:08 -0400

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.

Message #15 received at 3397 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: 3397 <at> debbugs.gnu.org
Subject: Re: bug#3397: NS: modeline shows inactive frame after make-frame
Date: Tue, 17 May 2016 18:58:02 +0100

Adrian Robert <adrian.b.robert <at> 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

Message #22 received at 3397 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: 3397 <at> debbugs.gnu.org
Subject: Re: bug#3397: NS: modeline shows inactive frame after make-frame
Date: Thu, 26 Aug 2021 19:40:05 +0100

Alan Third <alan <at> idiocy.org> writes:

> Adrian Robert <adrian.b.robert <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.