GNU bug report logs - #16097
Treat windows on other spaces as not visible in Cocoa

Previous Next

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

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

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

From: David Benjamin <davidben <at> google.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Treat windows on other spaces as not visible in Cocoa
Date: Mon, 9 Dec 2013 20:42:22 -0500

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

Here's a patch for something that's been bugging me. This makes Cmd-` cycle
through only the current space's windows, which is consistent with other
programs on OS X. It also matches the behavior of other-frame on X11 for
window managers that implement virtual desktops by mapping and unmapping
windows. The patch is attached.

It's not perfect; if you go into Mission Control or so and move a window
onto another space without switching spaces, it won't notice until you
switch spaces again. I wasn't able to find a notification to listen to;
it'd be nice to replace the visible field in a frame with some virtual call
that, in Cocoa, would just call out to [win isVisible] and [win
isOnActiveSpace], but that'd be a more invasive change. It also doesn't fix
the behavior where closing the last window on a space warps you to a window
on another space. I'm not sure yet what's causing that.

As far as copyright goes, if this is a large enough change to matter (a
decent chunk of the diff is just moving some code around), I'm a Google
employee. I'm told we already have an agreement on file with the FSF.

David Benjamin

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

[0001-In-nsterm-update-frame-visibility-on-space-change-an.patch (application/octet-stream, attachment)]

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

From: Stefan Kangas <stefan <at> marxist.se>
To: David Benjamin <davidben <at> google.com>
Cc: 16097 <at> debbugs.gnu.org
Subject: Re: bug#16097: [PATCH] Treat windows on other spaces as not visible
 in Cocoa
Date: Wed, 12 Aug 2020 15:34:04 -0700

David Benjamin <davidben <at> google.com> writes:

> Here's a patch for something that's been bugging me. This makes Cmd-` cycle through only the current space's windows, which is
> consistent with other programs on OS X. It also matches the behavior of other-frame on X11 for window managers that implement
> virtual desktops by mapping and unmapping windows. The patch is attached.
>
> It's not perfect; if you go into Mission Control or so and move a window onto another space without switching spaces, it won't notice
> until you switch spaces again. I wasn't able to find a notification to listen to; it'd be nice to replace the visible field in a frame with some
> virtual call that, in Cocoa, would just call out to [win isVisible] and [win isOnActiveSpace], but that'd be a more invasive change. It also
> doesn't fix the behavior where closing the last window on a space warps you to a window on another space. I'm not sure yet what's
> causing that.
>
> As far as copyright goes, if this is a large enough change to matter (a decent chunk of the diff is just moving some code around), I'm a
> Google employee. I'm told we already have an agreement on file with the FSF.

(This was sent 7 years ago but unfortunately never got a reply at the
time.)

The attached patch unfortunately no longer applies.

Is this still an issue on modern versions of Emacs?

Best regards,
Stefan Kangas

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 16097 <at> debbugs.gnu.org, David Benjamin <davidben <at> google.com>
Subject: Re: bug#16097: [PATCH] Treat windows on other spaces as not visible
 in Cocoa
Date: Tue, 13 Oct 2020 03:43:16 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

> Is this still an issue on modern versions of Emacs?

More information was requested two months ago, but none were given, so
I'm closing this bug report.  If this is something that's still a
problem, please respond to the debbugs address, and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: David Benjamin <davidben <at> google.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 16097 <at> debbugs.gnu.org, Stefan Kangas <stefan <at> marxist.se>
Subject: Re: bug#16097: [PATCH] Treat windows on other spaces as not visible
 in Cocoa
Date: Tue, 13 Oct 2020 12:05:57 -0400

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

I'm afraid that after seven years, I've long forgotten about this patch and
no longer use Emacs these days. But I did a quick build from source on
macOS, and it appears graphical Emacs still has this issue.

David

On Mon, Oct 12, 2020 at 9:43 PM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:

> Stefan Kangas <stefan <at> marxist.se> writes:
>
> > Is this still an issue on modern versions of Emacs?
>
> More information was requested two months ago, but none were given, so
> I'm closing this bug report.  If this is something that's still a
> problem, please respond to the debbugs address, and we'll reopen.
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>

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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: David Benjamin <davidben <at> google.com>
Cc: 16097 <at> debbugs.gnu.org, Stefan Kangas <stefan <at> marxist.se>
Subject: Re: bug#16097: [PATCH] Treat windows on other spaces as not visible
 in Cocoa
Date: Wed, 14 Oct 2020 06:09:04 +0200

David Benjamin <davidben <at> google.com> writes:

> I'm afraid that after seven years, I've long forgotten about this
> patch and no longer use Emacs these days. But I did a quick build from
> source on macOS, and it appears graphical Emacs still has this issue.

Thanks for testing; I'm reopening this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: David Benjamin <davidben <at> google.com>
Cc: Alan Third <alan <at> idiocy.org>, 16097 <at> debbugs.gnu.org
Subject: Re: bug#16097: [PATCH] Treat windows on other spaces as not visible
 in Cocoa
Date: Wed, 26 Jan 2022 17:46:15 +0100

David Benjamin <davidben <at> google.com> writes:

> Here's a patch for something that's been bugging me. This makes Cmd-`
> cycle through only the current space's windows, which is consistent
> with other programs on OS X. It also matches the behavior of
> other-frame on X11 for window managers that implement virtual desktops
> by mapping and unmapping windows. The patch is attached.

Perhaps Alan has a comment here; added to the CCs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 16097 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>,
 David Benjamin <davidben <at> google.com>
Subject: Re: bug#16097: [PATCH] Treat windows on other spaces as not visible
 in Cocoa
Date: Thu, 27 Jan 2022 12:06:36 +0100

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

>>>>> On Wed, 26 Jan 2022 17:46:15 +0100, Lars Ingebrigtsen <larsi <at> gnus.org> said:

    Lars> David Benjamin <davidben <at> google.com> writes:
    >> Here's a patch for something that's been bugging me. This makes Cmd-`
    >> cycle through only the current space's windows, which is consistent
    >> with other programs on OS X. It also matches the behavior of
    >> other-frame on X11 for window managers that implement virtual desktops
    >> by mapping and unmapping windows. The patch is attached.

    Lars> Perhaps Alan has a comment here; added to the CCs.

Please let's apply this. Please. Pretty please. Pretty please with sugar on
top. Please.

Iʼve rebased it to master and attach it here.

Did I mention I like it?

Robert
-- 

[0001-Make-other-frame-cycle-on-current-space-only-nsterm.patch (text/x-diff, attachment)]

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

From: Po Lu <luangruo <at> yahoo.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: David Benjamin <davidben <at> google.com>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 16097 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>
Subject: Re: bug#16097: [PATCH] Treat windows on other spaces as not visible
 in Cocoa
Date: Thu, 27 Jan 2022 21:59:44 +0800

Robert Pluim <rpluim <at> gmail.com> writes:

> Please let's apply this. Please. Pretty please. Pretty please with sugar on
> top. Please.

It breaks the fix for bug#53276 and probably the GNUstep build as well.

I don't use macOS and have no opinion about the feature in general, but
before applying it please give me a heads up, so I can fix bug#53276
again afterwards.

Thanks.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: David Benjamin <davidben <at> google.com>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 16097 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>
Subject: Re: bug#16097: [PATCH] Treat windows on other spaces as not visible
 in Cocoa
Date: Thu, 27 Jan 2022 15:23:30 +0100

>>>>> On Thu, 27 Jan 2022 21:59:44 +0800, Po Lu <luangruo <at> yahoo.com> said:

    Po> Robert Pluim <rpluim <at> gmail.com> writes:
    >> Please let's apply this. Please. Pretty please. Pretty please with sugar on
    >> top. Please.

    Po> It breaks the fix for bug#53276 and probably the GNUstep build as well.

So it does (and my patch contains an unrelated hunk, I probably
applied to an unclean tree).

    Po> I don't use macOS and have no opinion about the feature in general, but
    Po> before applying it please give me a heads up, so I can fix bug#53276
    Po> again afterwards.

It makes macOS consistent with other platforms. Anything that can
improve macOS' atrocious window handling is welcome.

We can try to retain the fix for 53276. Iʼd appreciate a hint :-)

Robert
-- 

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

From: Po Lu <luangruo <at> yahoo.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: David Benjamin <davidben <at> google.com>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 16097 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>
Subject: Re: bug#16097: [PATCH] Treat windows on other spaces as not visible
 in Cocoa
Date: Fri, 28 Jan 2022 08:35:10 +0800

Robert Pluim <rpluim <at> gmail.com> writes:

> We can try to retain the fix for 53276. Iʼd appreciate a hint :-)

Essentially, `updateVisibility' should be modified to declare a `struct
input_event', initialize that event, and use kbd_buffer_store_event
instead of the `emacs_event' global.

Thanks.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 16097 <at> debbugs.gnu.org
Subject: Re: bug#16097: [PATCH] Treat windows on other spaces as not visible
 in Cocoa
Date: Fri, 28 Jan 2022 09:17:24 +0100

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

>>>>> On Thu, 27 Jan 2022 20:58:11 +0000, Alan Third <alan <at> idiocy.org> said:

    Alan> On Thu, Jan 27, 2022 at 12:06:36PM +0100, Robert Pluim wrote:
    >> >>>>> On Wed, 26 Jan 2022 17:46:15 +0100, Lars Ingebrigtsen <larsi <at> gnus.org> said:
    >> 
    Lars> David Benjamin <davidben <at> google.com> writes:
    >> >> Here's a patch for something that's been bugging me. This makes Cmd-`
    >> >> cycle through only the current space's windows, which is consistent
    >> >> with other programs on OS X. It also matches the behavior of
    >> >> other-frame on X11 for window managers that implement virtual desktops
    >> >> by mapping and unmapping windows. The patch is attached.
    >> 
    Lars> Perhaps Alan has a comment here; added to the CCs.
    >> 
    >> Please let's apply this. Please. Pretty please. Pretty please with sugar on
    >> top. Please.
    >> 
    >> Iʼve rebased it to master and attach it here.
    >> 
    >> Did I mention I like it?

    Alan> I'm afraid I don't much. It looks like the updateVisibility method
    Alan> doesn't actually do enough to replace the windowDidBecomeKey method.

Thatʼs an artifact of me screwing up the patch, I think. But it
probably needs updating anyway, as Po pointed out.

    Alan> It also needs a good clean. For example there's a hunk that appears to
    Alan> just be removing a single blank line and most of the #ifdef's are
    Alan> redundant. I guess some of the weirdness in it is just because it's so
    Alan> old.

Sorry, I messed up the rebase. The attached should be better.

[0001-Make-other-frame-cycle-on-current-space-only-nsterm.patch (text/x-diff, attachment)]

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

Robert
-- 

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 16097 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 David Benjamin <davidben <at> google.com>, Alan Third <alan <at> idiocy.org>
Subject: Re: bug#16097: [PATCH] Treat windows on other spaces as not visible
 in Cocoa
Date: Fri, 28 Jan 2022 09:42:56 +0100

>>>>> On Fri, 28 Jan 2022 08:35:10 +0800, Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> said:

    Po> Robert Pluim <rpluim <at> gmail.com> writes:
    >> We can try to retain the fix for 53276. Iʼd appreciate a hint :-)

    Po> Essentially, `updateVisibility' should be modified to declare a `struct
    Po> input_event', initialize that event, and use kbd_buffer_store_event
    Po> instead of the `emacs_event' global.

I can do that, but blink-cursor-mode seems to be working fine with the
current changes (now that I actually know how itʼs supposed to function).

Robert
-- 

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

From: Po Lu <luangruo <at> yahoo.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 16097 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 David Benjamin <davidben <at> google.com>, Alan Third <alan <at> idiocy.org>
Subject: Re: bug#16097: [PATCH] Treat windows on other spaces as not visible
 in Cocoa
Date: Fri, 28 Jan 2022 16:47:05 +0800

Robert Pluim <rpluim <at> gmail.com> writes:

> I can do that, but blink-cursor-mode seems to be working fine with the
> current changes (now that I actually know how itʼs supposed to function).

Does it work fine right after the frame is created (and you never focus
into it afterwards?)

Thanks.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 16097 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 David Benjamin <davidben <at> google.com>, Alan Third <alan <at> idiocy.org>
Subject: Re: bug#16097: [PATCH] Treat windows on other spaces as not visible
 in Cocoa
Date: Fri, 28 Jan 2022 09:55:16 +0100

>>>>> On Fri, 28 Jan 2022 16:47:05 +0800, Po Lu <luangruo <at> yahoo.com> said:

    Po> Robert Pluim <rpluim <at> gmail.com> writes:
    >> I can do that, but blink-cursor-mode seems to be working fine with the
    >> current changes (now that I actually know how itʼs supposed to function).

    Po> Does it work fine right after the frame is created (and you never focus
    Po> into it afterwards?)

No, but then again current master doesnʼt blink the cursor then either.

Robert
-- 

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

From: Po Lu <luangruo <at> yahoo.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 16097 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 David Benjamin <davidben <at> google.com>, Alan Third <alan <at> idiocy.org>
Subject: Re: bug#16097: [PATCH] Treat windows on other spaces as not visible
 in Cocoa
Date: Fri, 28 Jan 2022 18:02:29 +0800

Robert Pluim <rpluim <at> gmail.com> writes:

>>>>>> On Fri, 28 Jan 2022 16:47:05 +0800, Po Lu <luangruo <at> yahoo.com> said:
>
>     Po> Robert Pluim <rpluim <at> gmail.com> writes:
>     >> I can do that, but blink-cursor-mode seems to be working fine with the
>     >> current changes (now that I actually know how itʼs supposed to function).
>
>     Po> Does it work fine right after the frame is created (and you never focus
>     Po> into it afterwards?)
>
> No, but then again current master doesnʼt blink the cursor then either.

Works on GNUstep for me (emacs -Q, obviously).  I also tried on macOS,
and it works there as well.  You have to launch it from GWorkspace or
the Finder for the first frame created to be the key window to test this
properly.

Thanks.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 16097 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 David Benjamin <davidben <at> google.com>, Alan Third <alan <at> idiocy.org>
Subject: Re: bug#16097: [PATCH] Treat windows on other spaces as not visible
 in Cocoa
Date: Fri, 28 Jan 2022 11:51:22 +0100

>>>>> On Fri, 28 Jan 2022 18:02:29 +0800, Po Lu <luangruo <at> yahoo.com> said:

    Po> Robert Pluim <rpluim <at> gmail.com> writes:
    >>>>>>> On Fri, 28 Jan 2022 16:47:05 +0800, Po Lu <luangruo <at> yahoo.com> said:
    >> 
    Po> Robert Pluim <rpluim <at> gmail.com> writes:
    >> >> I can do that, but blink-cursor-mode seems to be working fine with the
    >> >> current changes (now that I actually know how itʼs supposed to function).
    >> 
    Po> Does it work fine right after the frame is created (and you never focus
    Po> into it afterwards?)
    >> 
    >> No, but then again current master doesnʼt blink the cursor then either.

    Po> Works on GNUstep for me (emacs -Q, obviously).  I also tried on macOS,
    Po> and it works there as well.  You have to launch it from GWorkspace or
    Po> the Finder for the first frame created to be the key window to test this
    Po> properly.

Iʼd forgotten what a pain it is to get Emacs to launch from the Finder
as opposed to the cli. Anyway, the cursor blinks for me when launched
from the finder without a .emacs file

Robert
-- 

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

From: Po Lu <luangruo <at> yahoo.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 16097 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 David Benjamin <davidben <at> google.com>, Alan Third <alan <at> idiocy.org>
Subject: Re: bug#16097: [PATCH] Treat windows on other spaces as not visible
 in Cocoa
Date: Fri, 28 Jan 2022 19:06:56 +0800

Robert Pluim <rpluim <at> gmail.com> writes:

> Iʼd forgotten what a pain it is to get Emacs to launch from the Finder
> as opposed to the cli. Anyway, the cursor blinks for me when launched
> from the finder without a .emacs file

Interesting, so maybe something causes emacs_event to be non-NULL when
updateVisibility is called.

Though I still think we shouldn't take that chance and modify
updateVisibility to store events directly into the keyboard buffer.

Thanks.

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

From: Alan Third <alan <at> idiocy.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 16097 <at> debbugs.gnu.org
Subject: Re: bug#16097: [PATCH] Treat windows on other spaces as not visible
 in Cocoa
Date: Sat, 29 Jan 2022 00:16:24 +0000

On Fri, Jan 28, 2022 at 09:17:24AM +0100, Robert Pluim wrote:
> +- (void)updateVisibility: (NSNotification *)notification
> +{
> +  NSTRACE (updateVisibility);
> +
>    if (!emacsframe->output_data.ns)
>      return;
>  
> -  SET_FRAME_ICONIFIED (emacsframe, 1);
> -  SET_FRAME_VISIBLE (emacsframe, 0);
> +  NSWindow *win = [self window];
> +  BOOL on_active_space = YES;
> +  if ([win respondsToSelector: @selector (isOnActiveSpace)])
> +    on_active_space = [win isOnActiveSpace];
> +  if (on_active_space && [win isVisible])
> +    {
> +      if (FRAME_VISIBLE_P (emacsframe) && !FRAME_ICONIFIED_P (emacsframe))
> +        return;
>  
> -  if (emacs_event)
> +      SET_FRAME_ICONIFIED (emacsframe, 0);
> +      SET_FRAME_VISIBLE (emacsframe, 1);
> +      windows_or_buffers_changed = 63;
> +
> +      if (emacs_event)
> +        {
> +          emacs_event->kind = DEICONIFY_EVENT;
> +          EV_TRAILER ((id)nil);
> +        }
> +    }
> +  else
>      {
> -      emacs_event->kind = ICONIFY_EVENT;
> -      EV_TRAILER ((id)nil);
> +      if (!FRAME_VISIBLE_P (emacsframe) && FRAME_ICONIFIED_P (emacsframe))
> +        return;
> +
> +      SET_FRAME_ICONIFIED (emacsframe, 1);
> +      SET_FRAME_VISIBLE (emacsframe, 0);
> +
> +      if (emacs_event)
> +        {
> +          emacs_event->kind = ICONIFY_EVENT;
> +          EV_TRAILER ((id)nil);
> +        }
>      }
>  }

Why are we marking all frames not on the current space as iconified?
We're also, as far as I can tell, marking all invisible frames on the
current space as iconified too. We'll be sending these iconification
events to Emacs every time the space is switched, whether their status
has changed or not.

I'm unsure what happens to actually minimised frames here.

I'm still not sure this is the best approach versus, say modifying
candidate_frame in frame.c to check if the frame is on the active
space, similar to how it currently checks if the frames use the same
keyboard (which is a check that's not even relevant on macOS, afaict).

Even if it is the best approach it looks to me like it should really
be more streamlined. I don't think we want to call the same function
for (de)minimising and changing space. They strike me as distinctly
different operations and I think the conflation of the two is making
this code's logic... questionable.
-- 
Alan Third

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

From: Alan Third <alan <at> idiocy.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 16097 <at> debbugs.gnu.org
Subject: Re: bug#16097: [PATCH] Treat windows on other spaces as not visible
 in Cocoa
Date: Tue, 1 Feb 2022 22:48:02 +0000

(Apparently this failed to send correctly the first time. I know
Robert already replied to it, but it's not in the mailing list
archive, and I don't see my second follow up to this bug either.)

On Thu, Jan 27, 2022 at 12:06:36PM +0100, Robert Pluim wrote:
> >>>>> On Wed, 26 Jan 2022 17:46:15 +0100, Lars Ingebrigtsen <larsi <at> gnus.org> said:
> 
>     Lars> David Benjamin <davidben <at> google.com> writes:
>     >> Here's a patch for something that's been bugging me. This makes Cmd-`
>     >> cycle through only the current space's windows, which is consistent
>     >> with other programs on OS X. It also matches the behavior of
>     >> other-frame on X11 for window managers that implement virtual desktops
>     >> by mapping and unmapping windows. The patch is attached.
> 
>     Lars> Perhaps Alan has a comment here; added to the CCs.
> 
> Please let's apply this. Please. Pretty please. Pretty please with sugar on
> top. Please.
> 
> Iʼve rebased it to master and attach it here.
> 
> Did I mention I like it?

I'm afraid I don't much. It looks like the updateVisibility method
doesn't actually do enough to replace the windowDidBecomeKey method.

It also needs a good clean. For example there's a hunk that appears to
just be removing a single blank line and most of the #ifdef's are
redundant. I guess some of the weirdness in it is just because it's so
old.

Is this really how other terms work, where visibility is tied into
which virtual desktop is "active"?

I'm not against this behaviour, I just don't like the look of this
particular patch very much.

-- 
Alan Third

Previous Next

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