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

Previous Next

Package: emacs;

Reported by: Kai Ma <justksqsf <at> gmail.com>

Date: Wed, 15 Feb 2023 04:27:02 UTC

Severity: normal

Tags: patch

Found in version 29.0.60

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

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: 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.




This bug report was last modified 1 year and 270 days ago.

Previous Next


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