bug#61525: 29.0.60; delete-frame will raise frames in another virtual desktop

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: justksqsf@gmail.com
>> Date: Wed, 15 Feb 2023 16:41:41 +0100
>> From:  Daniel Martín via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> Daniel Martín via "Bug reports for GNU Emacs, the Swiss army knife of
>> text editors" <bug-gnu-emacs@gnu.org> writes:
>> 
>> >
>> > One downside of removing raise_frame is that, after you press C-x 5 0,
>> > you cannot start typing right away without first focusing on another
>> > Emacs frame manually.  People would consider this a regression from
>> > previous versions and something that doesn't happen on GNU/Linux.
>> >
>> > A possibly better approach could be:
>> >
>> > Once the "other" frame to select is chosen by the code that is just
>> > above in frame.c, call some Obj-C code that extracts the EmacsView and
>> > makes it the first responder:
>> >
>> > EmacsView *view = FRAME_NS_VIEW (frame1);
>> > [self makeFirstResponder:view];
>> >
>> > I haven't tested this, but perhaps this makes the other frame receive
>> > focus without switching desktops in a multi-desktop configuration.
>> 
>> The attached patch avoids the unwanted side effects of raise-frame by
>> making the other frame the key window, instead.  Could you give it a
>> try?
>
> Thanks.
>
>> +void ns_make_frame_key_window (struct frame *f)
>> +{
>> +  [[FRAME_NS_VIEW (f) window] makeKeyWindow];
>> +}

justksqsf@gmail.com, please write:

void
ns_make_frame_key_window (struct frame *f)
{
  ...
}

instead.

> Is this new call guaranteed to exist and work well on all the
> supported OS versions where we have the NS build?  I wouldn't want to
> fix this on some systems and break it on others at the same time.

Yes, this seems to exist in GNUstep (meaning that it should exist in an
old Mac OS as well.)