GNU bug report logs - #61525
29.0.60; delete-frame will raise frames in another virtual desktop

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 61525 in the body.
You can then email your comments to 61525 AT debbugs.gnu.org in the normal way.

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

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

From: Kai Ma <justksqsf <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.60; delete-frame will raise frames in another virtual desktop
Date: Wed, 15 Feb 2023 13:26:32 +0900

On MacOS, delete-frame can raise a frame in another virtual desktop,
which will cause switching between desktops.  This is annoying,
especially for emacsclient users.

To quote frame.c:

#ifdef NS_IMPL_COCOA
      else
	/* Under NS, there is no system mechanism for choosing a new
	   window to get focus -- it is left to application code.
	   So the portion of THIS application interfacing with NS
	   needs to know about it.  We call Fraise_frame, but the
	   purpose is really to transfer focus.  */
	Fraise_frame (frame1);
#endif

However, this has an undesired side effect: the desktop will be
switched.

Steps to reproduce:

1. Run emacs.
2. C-x 5 2, and move the new frame to another desktop.
3. C-x 5 0.  Now you see the desktop is switched.

This is a known issue for some time [1] and there is a patch that simply
disables raise_frame [2].  I'm not sure whether this patch is entirely
correct (and I think not).  But I do think the behavior should be
improved; at least the undesired desktop switching should be avoided.

Best regards,
Kai

[1] https://xenodium.com/no-emacs-frame-refocus-on-macos/
[2] https://github.com/d12frosted/homebrew-emacs-plus/blob/master/patches/emacs-28/no-frame-refocus-cocoa.patch

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

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Kai Ma <justksqsf <at> gmail.com>
Cc: 61525 <at> debbugs.gnu.org
Subject: Re: bug#61525: 29.0.60; delete-frame will raise frames in another
 virtual desktop
Date: Wed, 15 Feb 2023 11:54:17 +0100

Kai Ma <justksqsf <at> gmail.com> writes:

> On MacOS, delete-frame can raise a frame in another virtual desktop,
> which will cause switching between desktops.  This is annoying,
> especially for emacsclient users.
>
> To quote frame.c:
>
> #ifdef NS_IMPL_COCOA
>       else
> 	/* Under NS, there is no system mechanism for choosing a new
> 	   window to get focus -- it is left to application code.
> 	   So the portion of THIS application interfacing with NS
> 	   needs to know about it.  We call Fraise_frame, but the
> 	   purpose is really to transfer focus.  */
> 	Fraise_frame (frame1);
> #endif
>
> However, this has an undesired side effect: the desktop will be
> switched.
>
> Steps to reproduce:
>
> 1. Run emacs.
> 2. C-x 5 2, and move the new frame to another desktop.
> 3. C-x 5 0.  Now you see the desktop is switched.
>
> This is a known issue for some time [1] and there is a patch that simply
> disables raise_frame [2].  I'm not sure whether this patch is entirely
> correct (and I think not).  But I do think the behavior should be
> improved; at least the undesired desktop switching should be avoided.
>

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.

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

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Daniel Martín via "Bug reports for GNU Emacs, the Swiss
 army knife of text editors" <bug-gnu-emacs <at> gnu.org>
Cc: 61525 <at> debbugs.gnu.org, Kai Ma <justksqsf <at> gmail.com>
Subject: Re: bug#61525: 29.0.60; delete-frame will raise frames in another
 virtual desktop
Date: Wed, 15 Feb 2023 16:41:41 +0100

[Message part 1 (text/plain, inline)]

Daniel Martín via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> 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?

[0001-NS-Do-not-raise-a-different-frame-when-closing-a-fra.patch (text/x-patch, attachment)]

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

From: Kai Ma <justksqsf <at> gmail.com>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: 61525 <at> debbugs.gnu.org,
 "Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
Subject: Re: bug#61525: 29.0.60; delete-frame will raise frames in another
 virtual desktop
Date: Thu, 16 Feb 2023 00:49:41 +0900

> On Feb 16, 2023, at 00:41, Daniel Martín <mardani29 <at> yahoo.es> wrote:
> 
> Daniel Martín via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs <at> 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?
> 
> <0001-NS-Do-not-raise-a-different-frame-when-closing-a-fra.patch>

Thanks for the very fast fix!  I can confirm it works for me on macOS 13.1.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: 61525 <at> debbugs.gnu.org, justksqsf <at> gmail.com
Subject: Re: bug#61525: 29.0.60;
 delete-frame will raise frames in another virtual desktop
Date: Wed, 15 Feb 2023 19:08:19 +0200

> Cc: justksqsf <at> 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 <at> gnu.org>
> 
> Daniel Martín via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs <at> 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];
> +}

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.

Alternatively, can we come up with a change that does both what the
old code did and this addition?  That old code did work at some point,
I presume?

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

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61525 <at> debbugs.gnu.org, justksqsf <at> gmail.com
Subject: Re: bug#61525: 29.0.60; delete-frame will raise frames in another
 virtual desktop
Date: Thu, 16 Feb 2023 00:48:59 +0100

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> +void ns_make_frame_key_window (struct frame *f)
>> +{
>> +  [[FRAME_NS_VIEW (f) window] makeKeyWindow];
>> +}
>
> 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.

makeKeyWindow is a very old API that should be available on every macOS
and GNUstep we support, AFAIK.  I see usages of that API in other parts
of the NS build, in things as central as frame creation, and they are
not protected by any version or system check.

>
> Alternatively, can we come up with a change that does both what the
> old code did and this addition?  That old code did work at some point,
> I presume?

This is not the case of the old code breaking at some point.  It's a
difference in behavior between the GNU/Linux version of Emacs and the NS
version of Emacs.  In GNU/Linux, if you place an Emacs frame in a
separate desktop and press C-x 5 0, the window manager does not
automatically switch to the desktop where the other Emacs frames reside.

I don't know the reason why the NS build has been calling raise-frame
for so long.  I presume it was considered a good enough way to refocus
to another frame after closing one, in a world where virtual desktops
were not very common and the behavior reported by the OP was ignored.

I've attached a revised version of the patch, to fix a couple of code
style issues.

[0001-NS-Do-not-raise-a-different-frame-when-closing-a-fra.patch (text/x-patch, attachment)]

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61525 <at> debbugs.gnu.org, justksqsf <at> gmail.com,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#61525: 29.0.60; delete-frame will raise frames in another
 virtual desktop
Date: Thu, 16 Feb 2023 09:36:46 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: justksqsf <at> 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 <at> gnu.org>
>> 
>> Daniel Martín via "Bug reports for GNU Emacs, the Swiss army knife of
>> text editors" <bug-gnu-emacs <at> 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 <at> 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.)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: 61525 <at> debbugs.gnu.org, justksqsf <at> gmail.com
Subject: Re: bug#61525: 29.0.60; delete-frame will raise frames in another
 virtual desktop
Date: Thu, 16 Feb 2023 10:10:11 +0200

> From: Daniel Martín <mardani29 <at> yahoo.es>
> Cc: 61525 <at> debbugs.gnu.org,  justksqsf <at> gmail.com
> Date: Thu, 16 Feb 2023 00:48:59 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> +void ns_make_frame_key_window (struct frame *f)
> >> +{
> >> +  [[FRAME_NS_VIEW (f) window] makeKeyWindow];
> >> +}
> >
> > 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.
> 
> makeKeyWindow is a very old API that should be available on every macOS
> and GNUstep we support, AFAIK.  I see usages of that API in other parts
> of the NS build, in things as central as frame creation, and they are
> not protected by any version or system check.

Does this include the behavior?  That is, does that call behave the
same on all those versions?

> I don't know the reason why the NS build has been calling raise-frame
> for so long.  I presume it was considered a good enough way to refocus
> to another frame after closing one, in a world where virtual desktops
> were not very common and the behavior reported by the OP was ignored.

Did you try looking at Git history for this code?  Maybe the log
messages of the relevant commits and/or bug reports and/or discussions
on emacs-devel around the dates of the commits tell something about
the reasons?  I've seen too many cases where changing old code
introduced regressions because some aspect of the behavior was
disregarded, and would like to avoid that, certainly if this is for
the release branch.

Thanks.

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

From: Kai Ma <justksqsf <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61525 <at> debbugs.gnu.org, Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#61525: 29.0.60; delete-frame will raise frames in another
 virtual desktop
Date: Thu, 16 Feb 2023 17:31:40 +0900

[Message part 1 (text/plain, inline)]

> On Feb 16, 2023, at 17:10, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> Did you try looking at Git history for this code?  Maybe the log
> messages of the relevant commits and/or bug reports and/or discussions
> on emacs-devel around the dates of the commits tell something about
> the reasons?  I've seen too many cases where changing old code
> introduced regressions because some aspect of the behavior was
> disregarded, and would like to avoid that, certainly if this is for
> the release branch.

FWIW, the relevant commits:
 . edfda78355 first appeared as part of do_switch_frame
 . 06302656f3 changed
 . ac71ced75b moved to delete_frame

[Message part 2 (text/html, inline)]

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

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
 editors" <bug-gnu-emacs <at> gnu.org>
Cc: Po Lu <luangruo <at> yahoo.com>, 61525 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>, justksqsf <at> gmail.com
Subject: Re: bug#61525: 29.0.60; delete-frame will raise frames in another
 virtual desktop
Date: Thu, 16 Feb 2023 22:03:27 +0100

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

>
> justksqsf <at> gmail.com, please write:
>
> void
> ns_make_frame_key_window (struct frame *f)
> {
>   ...
> }
>
> instead.
>

Thanks, I've fixed that in the second version of the patch.

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

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61525 <at> debbugs.gnu.org, justksqsf <at> gmail.com
Subject: Re: bug#61525: 29.0.60; delete-frame will raise frames in another
 virtual desktop
Date: Thu, 16 Feb 2023 23:40:47 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>
> Does this include the behavior?  That is, does that call behave the
> same on all those versions?
>

I'd say yes, although as Apple software is non-free, it's difficult to
be 100% sure.

>
> Did you try looking at Git history for this code?  Maybe the log
> messages of the relevant commits and/or bug reports and/or discussions
> on emacs-devel around the dates of the commits tell something about
> the reasons?  I've seen too many cases where changing old code
> introduced regressions because some aspect of the behavior was
> disregarded, and would like to avoid that, certainly if this is for
> the release branch.

I'm OK to wait for if someone perhaps has a better idea to solve this
issue.  In any case, as the pretest is so close, I think that any change
in the area should go to Emacs 30.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: 61525 <at> debbugs.gnu.org, justksqsf <at> gmail.com
Subject: Re: bug#61525: 29.0.60; delete-frame will raise frames in another
 virtual desktop
Date: Fri, 17 Feb 2023 09:53:52 +0200

> From: Daniel Martín <mardani29 <at> yahoo.es>
> Cc: 61525 <at> debbugs.gnu.org,  justksqsf <at> gmail.com
> Date: Thu, 16 Feb 2023 23:40:47 +0100
> 
> > Did you try looking at Git history for this code?  Maybe the log
> > messages of the relevant commits and/or bug reports and/or discussions
> > on emacs-devel around the dates of the commits tell something about
> > the reasons?  I've seen too many cases where changing old code
> > introduced regressions because some aspect of the behavior was
> > disregarded, and would like to avoid that, certainly if this is for
> > the release branch.
> 
> I'm OK to wait for if someone perhaps has a better idea to solve this
> issue.  In any case, as the pretest is so close, I think that any change
> in the area should go to Emacs 30.

It's fine by me to install this on master.

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

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61525 <at> debbugs.gnu.org, justksqsf <at> gmail.com
Subject: Re: bug#61525: 29.0.60; delete-frame will raise frames in another
 virtual desktop
Date: Fri, 18 Aug 2023 15:20:41 +0200

[Message part 1 (text/plain, inline)]

Daniel Martín <mardani29 <at> yahoo.es> writes:
>
>>> +void ns_make_frame_key_window (struct frame *f)
>>> +{
>>> +  [[FRAME_NS_VIEW (f) window] makeKeyWindow];
>>> +}
>>
>> 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.
>
> makeKeyWindow is a very old API that should be available on every macOS
> and GNUstep we support, AFAIK.  I see usages of that API in other parts
> of the NS build, in things as central as frame creation, and they are
> not protected by any version or system check.
>

Got a report about some problems closing frames when Emacs runs inside a
macOS terminal.  So here's a new version of the patch that protects the
code that makes the other frame the key window, so that it only runs
when the frame is a GUI frame.

Kai Ma, could you give it a try and see if everything works well now?
Thanks.

[0001-PATCH-NS-Do-not-raise-a-different-frame-when-closing.patch (text/x-patch, attachment)]

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

From: Kai Ma <justksqsf <at> gmail.com>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: 61525 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#61525: 29.0.60; delete-frame will raise frames in another
 virtual desktop
Date: Fri, 18 Aug 2023 21:28:39 +0800

> On Aug 18, 2023, at 21:20, Daniel Martín <mardani29 <at> yahoo.es> wrote:
> 
> Daniel Martín <mardani29 <at> yahoo.es> writes:
>> 
>>>> +void ns_make_frame_key_window (struct frame *f)
>>>> +{
>>>> +  [[FRAME_NS_VIEW (f) window] makeKeyWindow];
>>>> +}
>>> 
>>> 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.
>> 
>> makeKeyWindow is a very old API that should be available on every macOS
>> and GNUstep we support, AFAIK.  I see usages of that API in other parts
>> of the NS build, in things as central as frame creation, and they are
>> not protected by any version or system check.
>> 
> 
> Got a report about some problems closing frames when Emacs runs inside a
> macOS terminal.  So here's a new version of the patch that protects the
> code that makes the other frame the key window, so that it only runs
> when the frame is a GUI frame.
> 
> Kai Ma, could you give it a try and see if everything works well now?
> Thanks.
> 
> <0001-PATCH-NS-Do-not-raise-a-different-frame-when-closing.patch>

Thanks.  Everything works fine now.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: 61525 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, justksqsf <at> gmail.com
Subject: Re: bug#61525: 29.0.60; delete-frame will raise frames in another
 virtual desktop
Date: Sat, 19 Aug 2023 11:26:57 +0800

Daniel Martín <mardani29 <at> yahoo.es> writes:

> * src/frame.h: Declare an NS-only function to make a frame the key
> window.
> * src/nsfns.m (ns_make_frame_key_window): Implement it.
> * src/frame.c (delete_frame): Call ns_make_frame_key_window instead of
> Fraise_frame.  (Bug#61525)

This commit message extends into column 70.  Please fill it to 64
columns, or else the ChangeLog entries generated will be incorrectly
formatted.

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

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 61525 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, justksqsf <at> gmail.com
Subject: Re: bug#61525: 29.0.60; delete-frame will raise frames in another
 virtual desktop
Date: Sat, 19 Aug 2023 10:28:48 +0200

[Message part 1 (text/plain, inline)]

Po Lu <luangruo <at> yahoo.com> writes:

> Daniel Martín <mardani29 <at> yahoo.es> writes:
>
>> * src/frame.h: Declare an NS-only function to make a frame the key
>> window.
>> * src/nsfns.m (ns_make_frame_key_window): Implement it.
>> * src/frame.c (delete_frame): Call ns_make_frame_key_window instead of
>> Fraise_frame.  (Bug#61525)
>
> This commit message extends into column 70.  Please fill it to 64
> columns, or else the ChangeLog entries generated will be incorrectly
> formatted.

I've attached a new patch with the commit message wrapped at 64 columns.

[0001-NS-Do-not-raise-a-different-frame-when-closing-a-fra.patch (text/x-patch, attachment)]

Message #66 received at 61525-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: luangruo <at> yahoo.com, 61525-done <at> debbugs.gnu.org, justksqsf <at> gmail.com
Subject: Re: bug#61525: 29.0.60; delete-frame will raise frames in another
 virtual desktop
Date: Sat, 26 Aug 2023 11:06:21 +0300

> From: Daniel Martín <mardani29 <at> yahoo.es>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  61525 <at> debbugs.gnu.org,  justksqsf <at> gmail.com
> Date: Sat, 19 Aug 2023 10:28:48 +0200
> 
> Po Lu <luangruo <at> yahoo.com> writes:
> 
> > Daniel Martín <mardani29 <at> yahoo.es> writes:
> >
> >> * src/frame.h: Declare an NS-only function to make a frame the key
> >> window.
> >> * src/nsfns.m (ns_make_frame_key_window): Implement it.
> >> * src/frame.c (delete_frame): Call ns_make_frame_key_window instead of
> >> Fraise_frame.  (Bug#61525)
> >
> > This commit message extends into column 70.  Please fill it to 64
> > columns, or else the ChangeLog entries generated will be incorrectly
> > formatted.
> 
> I've attached a new patch with the commit message wrapped at 64 columns.

Thanks, installed on the master branch, and closing the bug.

Previous Next

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