Subject: Re: bug#76814: 31.0.50; NS initial frame not raised

From: Ship Mints <[email-masked]>
Date: Fri, 7 Mar 2025 15:57:39 -0500

On Fri, Mar 7, 2025 at 3:53 PM Ship Mints <[email-masked]> wrote:

> On Fri, Mar 7, 2025 at 3:48 PM Alan Third <[email-masked]> wrote:
>
>> On Fri, Mar 07, 2025 at 08:10:54PM +0000, Stefan Kangas wrote:
>> > Ship Mints <[email-masked]> writes:
>> >
>> > > This is a behavior difference from 29 and 30.  In my init, I have to
>> > > manually raise the initial frame to avoid having to search for the new
>> > > frame using the Mac app switcher.
>> >
>> > I see this behavior with Emacs 28 and 29 too, when starting Emacs from a
>> > terminal window.  BTW, what is the workaround that you're using?
>> >
>> > Looking into this a little bit, I did find this API:
>> >
>> >     [main_window makeKeyAndOrderFront:nil];
>> >
>> >
>> https://developer.apple.com/documentation/appkit/nswindow/makekeyandorderfront(_
>> :)
>> >
>> > Alan, do you have any ideas or suggestions here?
>>
>> Not really. I do remember there was a bug report years ago about
>> new frames not being selected correctly. IIRC we never got to the
>> bottom of it... Bug#47731. I'm not sure this is the same thing, but
>> it sounds similar.
>>
>> Why it would suddenly be more of an issue in Emacs 30? I've no idea.
>>
>
> I just tested my 29.4 and it works fine.  I see Gerd added:
>
>   @interface EmacsView : NSView <NSTextInput, NSTextInputClient,
> NSWindowDelegate>
>
> where 29.4 was:
>
>   @interface EmacsView : NSView <NSTextInput, NSWindowDelegate>
>
> It's not obvious to me why that would matter but that's the most immediate
> thing that jumps out.
>

I built master without NSTextInputClient and still the same so that's a red
herring.