GNU bug report logs - #58945
29.0.50; Setting frame name in pgtk Emacs is asynchronous

Previous Next

Package: emacs;

Reported by: Thibault Polge <thibault <at> thb.lt>

Date: Tue, 1 Nov 2022 14:59:01 UTC

Severity: normal

Tags: notabug

Found in version 29.0.50

Done: Stefan Kangas <stefankangas <at> gmail.com>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#58945; Package emacs. (Tue, 01 Nov 2022 14:59:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thibault Polge <thibault <at> thb.lt>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 01 Nov 2022 14:59:01 GMT) Full text and rfc822 format available.

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

From: Thibault Polge <thibault <at> thb.lt>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Setting frame name in pgtk Emacs is asynchronous
Date: Tue, 01 Nov 2022 15:58:22 +0100
[Message part 1 (text/plain, inline)]
In pgtk Emacs (built from a very recent git HEAD), running under the
Sway window manager, setting a frame name like this:

(set-frame-parameter (selected-frame) 'name "Some new name")
(redisplay t)

Doesn't immediately take effect.

The example program below demonstrates this by triggering a race
condition: it renames all frames, then immediately requests the state of
the Sway window manager, and renames them back. Repeatedly eval'ing the
final sexp randomly returns either the original or the renamed frame
names. (When testing with a few frames, it never returned a mix of
original or renamed names --- it's 100% one or the other)

This is an issue because frame names is the only way to associate Emacs
frames with Sway identifiers (or any wayland wm) on pgtk Emacs).

MWE code follows.

Best regards,
Thibault

[mwe.el (application/emacs-lisp, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58945; Package emacs. (Thu, 03 Nov 2022 00:32:02 GMT) Full text and rfc822 format available.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Thibault Polge <thibault <at> thb.lt>
Cc: 58945 <at> debbugs.gnu.org
Subject: Re: bug#58945: 29.0.50; Setting frame name in pgtk Emacs is
 asynchronous
Date: Thu, 03 Nov 2022 08:31:30 +0800
tags 58945 notabug
thanks

Thibault Polge <thibault <at> thb.lt> writes:

> In pgtk Emacs (built from a very recent git HEAD), running under the
> Sway window manager, setting a frame name like this:
>
> (set-frame-parameter (selected-frame) 'name "Some new name")
> (redisplay t)
>
> Doesn't immediately take effect.
>
> The example program below demonstrates this by triggering a race
> condition: it renames all frames, then immediately requests the state of
> the Sway window manager, and renames them back. Repeatedly eval'ing the
> final sexp randomly returns either the original or the renamed frame
> names. (When testing with a few frames, it never returned a mix of
> original or renamed names --- it's 100% one or the other)
>
> This is an issue because frame names is the only way to associate Emacs
> frames with Sway identifiers (or any wayland wm) on pgtk Emacs).

Setting the title on Wayland is asynchronous, just as it is with X.  By
the time the request or PropertyNotify event reaches the compositor or
window manager, other processes may already have run.  In addition,
running asynchronously improves performance.

I would recommend just waiting a set delay after setting the title.




Added tag(s) notabug. Request was from Po Lu <luangruo <at> yahoo.com> to control <at> debbugs.gnu.org. (Thu, 03 Nov 2022 00:32:02 GMT) Full text and rfc822 format available.

Reply sent to Stefan Kangas <stefankangas <at> gmail.com>:
You have taken responsibility. (Sat, 12 Nov 2022 20:35:08 GMT) Full text and rfc822 format available.

Notification sent to Thibault Polge <thibault <at> thb.lt>:
bug acknowledged by developer. (Sat, 12 Nov 2022 20:35:08 GMT) Full text and rfc822 format available.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Thibault Polge <thibault <at> thb.lt>, 58945-done <at> debbugs.gnu.org
Subject: Re: bug#58945: 29.0.50;
 Setting frame name in pgtk Emacs is asynchronous
Date: Sat, 12 Nov 2022 12:34:15 -0800
Po Lu <luangruo <at> yahoo.com> writes:

> tags 58945 notabug
> thanks
>
> Thibault Polge <thibault <at> thb.lt> writes:
>
>> In pgtk Emacs (built from a very recent git HEAD), running under the
>> Sway window manager, setting a frame name like this:
>>
>> (set-frame-parameter (selected-frame) 'name "Some new name")
>> (redisplay t)
>>
>> Doesn't immediately take effect.
>>
>> The example program below demonstrates this by triggering a race
>> condition: it renames all frames, then immediately requests the state of
>> the Sway window manager, and renames them back. Repeatedly eval'ing the
>> final sexp randomly returns either the original or the renamed frame
>> names. (When testing with a few frames, it never returned a mix of
>> original or renamed names --- it's 100% one or the other)
>>
>> This is an issue because frame names is the only way to associate Emacs
>> frames with Sway identifiers (or any wayland wm) on pgtk Emacs).
>
> Setting the title on Wayland is asynchronous, just as it is with X.  By
> the time the request or PropertyNotify event reaches the compositor or
> window manager, other processes may already have run.  In addition,
> running asynchronously improves performance.
>
> I would recommend just waiting a set delay after setting the title.

No further comments within 1 week, so I'm closing this bug report.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 11 Dec 2022 12:24:08 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 192 days ago.

Previous Next


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