GNU bug report logs - #49959
28.0.50; Emacs got quasi freeze

Previous Next

Package: emacs;

Reported by: 野宮 賢 / NOMIYA Masaru <m.nomiya <at> gmail.com>

Date: Mon, 9 Aug 2021 15:04:02 UTC

Severity: normal

Tags: moreinfo

Merged with 49955

Found in version 28.0.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

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 49959 in the body.
You can then email your comments to 49959 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#49959; Package emacs. (Mon, 09 Aug 2021 15:04:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to 野宮 賢 / NOMIYA Masaru <m.nomiya <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 09 Aug 2021 15:04:03 GMT) Full text and rfc822 format available.

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

From: 野宮 賢 / NOMIYA Masaru
 <m.nomiya <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Emacs got quasi freeze
Date: Mon, 09 Aug 2021 18:12:32 +0900
Hello.

With this pacth;

commit 483c5e953c12a95382bef4a3b6769a680c32fe86
Author: Martin Rudalics <rudalics <at> gmx.at>
Date:   Wed May 5 10:26:32 2021 +0200

    Fix two GTK3 event handling issues
    
    * src/xterm.c (handle_one_xevent): For GTK3 PropertyNotify and
    MapNotify events explicitly request the stored frame sizes when
    the frame changes from iconified to a non-hidden state
    (Bug#24526).  For Expose events do not change the frame's
    visibility or iconified state.  For FocusIn events on GTK3 do
    not apply the fix for Bug#42655.  The latter two changes are to
    avoid that plain invisible frames get reported as iconified.

Emacs has often got a quasi freeze, not perfect freeze but doesn't
accept any openraion except quitting operation.

Sorry for the report only.

Regards.

---
┏━━┓彡 Masaru Nomiya             mail-to: nomiya @ galaxy.dti.ne.jp
┃\/彡
┗━━┛ "Three young men died for Rationalization.
           Yet, Margaret Bloody Thatcher LIVES!"
                                            'Brassed Off'




Forcibly Merged 49955 49959. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 09 Aug 2021 15:07:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Wed, 18 Aug 2021 08:04:01 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: 野宮 賢 / NOMIYA Masaru
 <m.nomiya <at> gmail.com>, 49959 <at> debbugs.gnu.org
Subject: Re: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Wed, 18 Aug 2021 10:03:50 +0200
> With this pacth;
>
> commit 483c5e953c12a95382bef4a3b6769a680c32fe86
> Author: Martin Rudalics <rudalics <at> gmx.at>
> Date:   Wed May 5 10:26:32 2021 +0200
>
>      Fix two GTK3 event handling issues
>
>      * src/xterm.c (handle_one_xevent): For GTK3 PropertyNotify and
>      MapNotify events explicitly request the stored frame sizes when
>      the frame changes from iconified to a non-hidden state
>      (Bug#24526).  For Expose events do not change the frame's
>      visibility or iconified state.  For FocusIn events on GTK3 do
>      not apply the fix for Bug#42655.  The latter two changes are to
>      avoid that plain invisible frames get reported as iconified.
>
> Emacs has often got a quasi freeze, not perfect freeze but doesn't
> accept any openraion except quitting operation.
>
> Sorry for the report only.

I assume that you have bisected the sources and reverted the above
commit in order to be sure that it really is the culprit.  Right?

Did you also follow the discussions in Bug#48413 and Bug#48268?  Can you
observe any of the symptoms mentioned there (blank screens, no redraws)
on your system?  Do you have to, for example, switch desktops to make
the freeze happen?  Can you imagine anything "untypical" for Emacs users
in your editing behavior that could provoke the freezes?

In either case, can you try to isolate the part(s) of the above commit
that are responsible for the freezes - in the worst case we'll have to
make them optional then.  And maybe you could also try to build with
GTK2 (and ideally with Lucid) so we can tell whether these freezes are
toolkit dependent.

You can also try to set `frame-size-history' to some positive number and
look at the most recent entries after a freeze has been broken and post
here what `frame--size-history' prints.  Maybe they can give us some
clues.

Finally, please give us more details about how your Emacs is configured
and which desktop and window manager you use.

Thanks in advance, martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Sat, 21 Aug 2021 05:10:01 GMT) Full text and rfc822 format available.

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

From: Masaru Nomiya <nomiya <at> galaxy.dti.ne.jp>
To: 49959 <at> debbugs.gnu.org
Subject: Re: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Sat, 21 Aug 2021 14:09:28 +0900
Hello,

In the Message; 

  Subject    : Re: bug#49959: 28.0.50; Emacs got quasi freeze
  Message-ID : <ea89e7fd-91f1-362e-7fdc-0be58e044390 <at> gmx.at>
  Date & Time: Wed, 18 Aug 2021 10:03:50 +0200

[MR] == martin rudalics <rudalics <at> gmx.at> has written:

MN> > With this pacth;

MN> > commit 483c5e953c12a95382bef4a3b6769a680c32fe86
MN> > Author: Martin Rudalics <rudalics <at> gmx.at>
MN> > Date:   Wed May 5 10:26:32 2021 +0200
[...]
MN> > Emacs has often got a quasi freeze, not perfect freeze but doesn't
MN> > accept any openraion except quitting operation.
>
MN> > Sorry for the report only.

[...]
MR>  Finally, please give us more details about how your Emacs is configured
MR>  and which desktop and window manager you use.

WM, enlightenment (git head), was the cause.
With my report, the deveopper gave me the patch of enlightenment, then
the issue has gone.

BTW.

My environments;

1. OS:  openSUSE Leap 15.3
2. WM:  enlightenment (git head)
3. my configure;

   ./configure --with-x-toolkit=gtk3 --without-xim --prefix=/usr/local --without-sound --build=x86_64-openSUSE-linux-gnu --host=x86_64-openSUSE-linux-gnu --with-modules --with-mailutils --without-libsystemd --with-gconf --with-imagemagick --with-harfbuzz --with-json --with-xwidgets

Thanks.

---
┏━━┓彡 Masaru Nomiya             mail-to: nomiya @ galaxy.dti.ne.jp
┃\/彡
┗━━┛ "Bill! You married with Computer.
          Not with Me!"
         "No..., with money."




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Sat, 21 Aug 2021 06:55:02 GMT) Full text and rfc822 format available.

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

From: Masaru Nomiya <nomiya <at> galaxy.dti.ne.jp>
To: 49959 <at> debbugs.gnu.org
Subject: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Sat, 21 Aug 2021 15:54:06 +0900
Hello,

In the Message; 

  Subject    : bug#49959: 28.0.50; Emacs got quasi freeze
  Message-ID : <8735r3idtj.wl-nomiya <at> galaxy.dti.ne.jp>
  Date & Time: Sat, 21 Aug 2021 14:09:28 +0900

[MN] == Masaru Nomiya <nomiya <at> galaxy.dti.ne.jp> has written:

MN> Hello,

MN> In the Message; 

MN>   Subject    : Re: bug#49959: 28.0.50; Emacs got quasi freeze
MN>   Message-ID : <ea89e7fd-91f1-362e-7fdc-0be58e044390 <at> gmx.at>
MN>   Date & Time: Wed, 18 Aug 2021 10:03:50 +0200

MN> [MR] == martin rudalics <rudalics <at> gmx.at> has written:

MN> > With this pacth;

MN> > commit 483c5e953c12a95382bef4a3b6769a680c32fe86
MN> > Author: Martin Rudalics <rudalics <at> gmx.at>
MN> > Date:   Wed May 5 10:26:32 2021 +0200
MN> [...]
MN> > Emacs has often got a quasi freeze, not perfect freeze but doesn't
MN> > accept any openraion except quitting operation.
MN> >
MN> > Sorry for the report only.

MN> [...]
MR>  Finally, please give us more details about how your Emacs is configured
MR>  and which desktop and window manager you use.

MN> WM, enlightenment (git head), was the cause.
MN> With my report, the deveopper gave me the patch of enlightenment, then
MN> the issue has gone.

Sorry, the enlightenment's developper said,that there exists a bug in
the git head as follows;

In the Message; 

  Subject    : Re: [e-users] emacs problem persists
  Message-ID : <20210821072303.ead4637113305e2e518936b8 <at> rasterman.com>
  Date & Time: Sat, 21 Aug 2021 07:23:03 +0100

[Dev] == Dev <xxxx <at> xxxx.com> has written:

CH>  This is not a fix. it is a test. You have an emacs bug. It
CH>  doesn't handle the hidden state changes properly and chooses to
CH>  not render updates. :) But you can now tell them what the bug is.

---
┏━━┓彡 Masaru Nomiya             mail-to: nomiya @ galaxy.dti.ne.jp
┃\/彡
┗━━┛ "Three young men died for Rationalization.
           Yet, Margaret Bloody Thatcher LIVES!"
                                            'Brassed Off'




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Sun, 22 Aug 2021 08:24:01 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: m.nomiya <at> gmail.com, 49959 <at> debbugs.gnu.org
Subject: Re: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Sun, 22 Aug 2021 10:23:48 +0200
> Sorry, the enlightenment's developper said,that there exists a bug in
> the git head as follows;
>
> In the Message;
>
>    Subject    : Re: [e-users] emacs problem persists
>    Message-ID : <20210821072303.ead4637113305e2e518936b8 <at> rasterman.com>
>    Date & Time: Sat, 21 Aug 2021 07:23:03 +0100
>
> [Dev] == Dev <xxxx <at> xxxx.com> has written:
>
> CH>  This is not a fix. it is a test. You have an emacs bug. It
> CH>  doesn't handle the hidden state changes properly and chooses to
> CH>  not render updates. :) But you can now tell them what the bug is.

Could you please ask the developer what the bug really is?  Which are
the hidden changes and in which sense do we not render updates?  What
should we do better?

Thank you for any enlightenment in this area, martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Sun, 22 Aug 2021 09:50:01 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: m.nomiya <at> gmail.com, 49959 <at> debbugs.gnu.org
Subject: Re: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Sun, 22 Aug 2021 11:49:40 +0200
> Could you please ask the developer what the bug really is?  Which are
> the hidden changes and in which sense do we not render updates?  What
> should we do better?
>
> Thank you for any enlightenment in this area, martin

Maybe the problem can be summarized as follows:

- Emacs is in a state where a frame is hidden but not iconified.

- Emacs gets a PropertyNotify event but does not react because the frame
  was in its understanding _not_ iconified before.  Elightenment thinks
  that Emacs should understand that the frame is visible now and react
  properly.

If that's the case, then Emacs had this problem ever since.  Actually,
Emacs here waits for a MapNotify event to arrive but apparently this
does not happen with Elightenment.

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Sun, 22 Aug 2021 16:55:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: m.nomiya <at> gmail.com, 49959 <at> debbugs.gnu.org
Subject: Re: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Sun, 22 Aug 2021 18:54:11 +0200
[Message part 1 (text/plain, inline)]
> Maybe the problem can be summarized as follows:
>
> - Emacs is in a state where a frame is hidden but not iconified.
>
> - Emacs gets a PropertyNotify event but does not react because the frame
>    was in its understanding _not_ iconified before.  Elightenment thinks
>    that Emacs should understand that the frame is visible now and react
>    properly.
>
> If that's the case, then Emacs had this problem ever since.  Actually,
> Emacs here waits for a MapNotify event to arrive but apparently this
> does not happen with Elightenment.

A preliminary patch based on the above remarks is attached.

martin
[deiconify.diff (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Sun, 22 Aug 2021 23:12:02 GMT) Full text and rfc822 format available.

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

From: Masaru Nomiya <nomiya <at> galaxy.dti.ne.jp>
To: 49959 <at> debbugs.gnu.org
Subject: Re: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Mon, 23 Aug 2021 08:11:37 +0900
Hello,

Sorry for late reply.

In the Message; 

  Subject    : bug#49959: 28.0.50; Emacs got quasi freeze
  Message-ID : <b0008bc4-4715-5313-2e10-5631092437a1 <at> gmx.at>
  Date & Time: Sun, 22 Aug 2021 18:54:11 +0200

[RM] == martin rudalics <rudalics <at> gmx.at> has written:

RM>  [1  <text/plain; utf-8 (7bit)>]
RM>  > Maybe the problem can be summarized as follows:
RM>  >
RM>  > - Emacs is in a state where a frame is hidden but not iconified.
RM>  >
RM>  > - Emacs gets a PropertyNotify event but does not react because the frame
RM>  >    was in its understanding _not_ iconified before.  Elightenment thinks
RM>  >    that Emacs should understand that the frame is visible now and react
RM>  >    properly.
RM>  >
RM>  > If that's the case, then Emacs had this problem ever since.  Actually,
RM>  > Emacs here waits for a MapNotify event to arrive but apparently this
RM>  > does not happen with Elightenment.

RM>  A preliminary patch based on the above remarks is attached.

Thanks, but it's off the mark.

The issue is around rendering. The phnomenon is;

> If i move to another virtual desktop, and then return to
> the one with the emacs window, it looks like emacs never gets focus.
> Enlightenment's borders do change colours to indicate it has focus,
> but the cursor remains an empty box instead of a solid rectangle.
> Typing in the window also shows nothing happening. Until... If i
> minimize the window and bring it back, or if i shade and unshade the
> window, it all looks ok again, and everything i typed is there! So i
> can be typing blindly with nothing appearing in the window, then shade
> and unshade, and see that everything i typed (more often than not on
> the wrong line, because i couldn't see it).

Regards.

---
┏━━┓彡 Masaru Nomiya             mail-to: nomiya @ galaxy.dti.ne.jp
┃\/彡
┗━━┛ "No Windows, no gains!" ..... "Why, I am wrong?"
        
                                          -- Bill --




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Mon, 23 Aug 2021 08:36:01 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: m.nomiya <at> gmail.com, 49959 <at> debbugs.gnu.org
Subject: Re: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Mon, 23 Aug 2021 10:35:02 +0200
[Message part 1 (text/plain, inline)]
> The issue is around rendering. The phnomenon is;

Please always tell us right away what you are doing to produce the
faulty behavior.

>> If i move to another virtual desktop, and then return to
>> the one with the emacs window, it looks like emacs never gets focus.
>> Enlightenment's borders do change colours to indicate it has focus,
>> but the cursor remains an empty box instead of a solid rectangle.
>> Typing in the window also shows nothing happening. Until... If i
>> minimize the window and bring it back, or if i shade and unshade the
>> window, it all looks ok again, and everything i typed is there! So i
>> can be typing blindly with nothing appearing in the window, then shade
>> and unshade, and see that everything i typed (more often than not on
>> the wrong line, because i couldn't see it).

From what I understand till now, Enlightenment treats the Emacs window
as invisible when switching away from its desktop.  So what we have to
know is what Enlightenment sends to Emacs when the user returns to the
desktop with the Emacs window.  Is it a PropertyNotify, a MapNotify, a
VisibilityNotify, a FocusIn or some other event?

If it is a VisibilityNotify event, then maybe the attached patch will
help.

Thanks, martin
[VisibilityNotify.diff (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Tue, 24 Aug 2021 01:20:01 GMT) Full text and rfc822 format available.

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

From: Masaru Nomiya <nomiya <at> galaxy.dti.ne.jp>
To: 49959 <at> debbugs.gnu.org
Subject: Re: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Tue, 24 Aug 2021 10:19:36 +0900
Hello,

In the Message; 

  Subject    : bug#49959: 28.0.50; Emacs got quasi freeze
  Message-ID : <ed3f250a-e125-a1de-45d9-2dc938214743 <at> gmx.at>
  Date & Time: Mon, 23 Aug 2021 10:35:02 +0200

[RM] == martin rudalics <rudalics <at> gmx.at> has written:

RM>  [1  <text/plain; utf-8 (7bit)>]
RM>  > The issue is around rendering. The phnomenon is;

RM>  Please always tell us right away what you are doing to produce the
RM>  faulty behavior.

I'm so sory,

Now, I understand the debugging method.

[...]
RM>  From what I understand till now, Enlightenment treats the Emacs window
RM>  as invisible when switching away from its desktop.  So what we have to
RM>  know is what Enlightenment sends to Emacs when the user returns to the
RM>  desktop with the Emacs window.  Is it a PropertyNotify, a MapNotify, a
RM>  VisibilityNotify, a FocusIn or some other event?

RM>  If it is a VisibilityNotify event, then maybe the attached patch will
RM>  help.

RM>  Thanks, martin
RM>  [2 VisibilityNotify.diff <text/x-patch (7bit)>]
RM>  diff --git a/src/xterm.c b/src/xterm.c
RM>  index 6c6a62adb2..6e562ce8e9 100644
RM>  --- a/src/xterm.c
RM>  +++ b/src/xterm.c
RM>  @@ -9354,7 +9354,11 @@ handle_one_xevent (struct x_display_info *dpyinfo,
RM>         f = x_top_window_to_frame (dpyinfo, event->xvisibility.window);
RM>         if (f && (event->xvisibility.state == VisibilityUnobscured
RM>   		|| event->xvisibility.state == VisibilityPartiallyObscured))
RM>  -	SET_FRAME_VISIBLE (f, 1);
RM>  +	{
RM>  +	  f->output_data.x->has_been_visible = true;
RM>  +	  SET_FRAME_GARBAGED (f);
RM>  +	  SET_FRAME_VISIBLE (f, 1);
RM>  +	}

RM>         goto OTHER;

Thanks.

I'll check with this pacth.

Regards.

---
┏━━┓彡 Masaru Nomiya             mail-to: nomiya @ galaxy.dti.ne.jp
┃\/彡
┗━━┛ "Three young men died for Rationalization.
           Yet, Margaret Bloody Thatcher LIVES!"
                                            'Brassed Off'




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Tue, 24 Aug 2021 03:46:02 GMT) Full text and rfc822 format available.

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

From: Masaru Nomiya <nomiya <at> galaxy.dti.ne.jp>
To: 49959 <at> debbugs.gnu.org
Subject: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Tue, 24 Aug 2021 12:45:51 +0900
Hello,

In the Message; 

  Subject    : bug#49959: 28.0.50; Emacs got quasi freeze
  Message-ID : <87o89nmyfr.wl-nomiya <at> galaxy.dti.ne.jp>
  Date & Time: Tue, 24 Aug 2021 10:19:36 +0900

[MN] == Masaru Nomiya <nomiya <at> galaxy.dti.ne.jp> has written:

MN> Hello,

MN> In the Message; 

MN>   Subject    : bug#49959: 28.0.50; Emacs got quasi freeze
MN>   Message-ID : <ed3f250a-e125-a1de-45d9-2dc938214743 <at> gmx.at>
MN>   Date & Time: Mon, 23 Aug 2021 10:35:02 +0200

[...]
RM>  If it is a VisibilityNotify event, then maybe the attached patch will
RM>  help.

RM>  Thanks, martin
RM>  [2 VisibilityNotify.diff <text/x-patch (7bit)>]
RM>  diff --git a/src/xterm.c b/src/xterm.c
RM>  index 6c6a62adb2..6e562ce8e9 100644
RM>  --- a/src/xterm.c
RM>  +++ b/src/xterm.c
RM>  @@ -9354,7 +9354,11 @@ handle_one_xevent (struct x_display_info *dpyinfo,
RM>         f = x_top_window_to_frame (dpyinfo, event->xvisibility.window);
RM>         if (f && (event->xvisibility.state == VisibilityUnobscured
RM>   		|| event->xvisibility.state == VisibilityPartiallyObscured))
RM>  -	SET_FRAME_VISIBLE (f, 1);
RM>  +	{
RM>  +	  f->output_data.x->has_been_visible = true;
RM>  +	  SET_FRAME_GARBAGED (f);
RM>  +	  SET_FRAME_VISIBLE (f, 1);
RM>  +	}

RM>         goto OTHER;

MN> Thanks.

MN> I'll check with this pacth.

Sorry, but it's off the mark.

That is, when

Tue Aug 24 12:37:39 JST 2021
_NET_WM_STATE(ATOM) = _NET_WM_STATE_HIDDEN

appears, it doesn't start rendering (= enlightenment doesn't remove
this property).

Thanks.

---
┏━━┓彡 Masaru Nomiya             mail-to: nomiya @ galaxy.dti.ne.jp
┃\/彡
┗━━┛ "Three young men died for Rationalization.
           Yet, Margaret Bloody Thatcher LIVES!"
                                            'Brassed Off'




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Tue, 24 Aug 2021 09:43:01 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: m.nomiya <at> gmail.com, 49959 <at> debbugs.gnu.org
Subject: Re: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Tue, 24 Aug 2021 11:41:52 +0200
[Message part 1 (text/plain, inline)]
> That is, when
>
> Tue Aug 24 12:37:39 JST 2021
> _NET_WM_STATE(ATOM) = _NET_WM_STATE_HIDDEN
>
> appears, it doesn't start rendering (= enlightenment doesn't remove
> this property).

So it _is_ a PropertyNotify event we should react to.  I'll attach yet
another patch to that purpose.

martin
[enlightenment.diff (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Tue, 24 Aug 2021 12:36:01 GMT) Full text and rfc822 format available.

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

From: Masaru Nomiya <nomiya <at> galaxy.dti.ne.jp>
To: 49959 <at> debbugs.gnu.org
Subject: Re: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Tue, 24 Aug 2021 21:35:09 +0900
Hello,

In the Message; 

  Subject    : bug#49959: 28.0.50; Emacs got quasi freeze
  Message-ID : <35b2918d-5755-01e0-ecc9-ec543ee83299 <at> gmx.at>
  Date & Time: Tue, 24 Aug 2021 11:41:52 +0200

[RM] == martin rudalics <rudalics <at> gmx.at> has written:

RM>  [1  <text/plain; utf-8 (7bit)>]
RM>  > That is, when
RM>  >
RM>  > Tue Aug 24 12:37:39 JST 2021
RM>  > _NET_WM_STATE(ATOM) = _NET_WM_STATE_HIDDEN
RM>  >
RM>  > appears, it doesn't start rendering (= enlightenment doesn't remove
RM>  > this property).

RM>  So it _is_ a PropertyNotify event we should react to.  I'll attach yet
RM>  another patch to that purpose.

RM>  martin
RM>  [2 enlightenment.diff <text/x-patch (quoted-printable)>]
RM>  diff --git a/src/termhooks.h b/src/termhooks.h
RM>  index 1d3cdc8fe8..479b8a1c29 100644
[...]
RM>  +	  f->output_data.x->has_been_visible = true;
RM>  +	  SET_FRAME_GARBAGED (f);
RM>  +	  SET_FRAME_VISIBLE (f, 1);
RM>  +	}

RM>         goto OTHER;

Sorry, but without avail.

Thanks.

---
┏━━┓彡     Masaru Nomiya              mail-to: nomiya @ galaxy.dti.ne.jp
┃\/彡
┗━━┛ "Tim Cook, the C.E.O. of Apple, said earlier this year that he would
o	   not let his nephew join social networks. Bill Gates banned cellphone
	   until his children were teenagers, and Melinda Gates wrote that she	            wished they had waited even longer. Steve Jobs would not let his young
	   children near iPads."
-- 'A Dark Consensus About Screens and Kids Begins to Emerge in Silicon Valley - The New York Times' --






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Tue, 24 Aug 2021 14:15:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: m.nomiya <at> gmail.com, 49959 <at> debbugs.gnu.org
Subject: Re: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Tue, 24 Aug 2021 16:14:37 +0200
[Message part 1 (text/plain, inline)]
> Sorry, but without avail.

One escalation more.

martin
[enlightenment.diff (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Wed, 25 Aug 2021 11:02:02 GMT) Full text and rfc822 format available.

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

From: Masaru Nomiya <nomiya <at> galaxy.dti.ne.jp>
To: 49959 <at> debbugs.gnu.org
Subject: Re: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Wed, 25 Aug 2021 20:01:22 +0900
Hello,

In the Message; 

  Subject    : Re: bug#49959: 28.0.50; Emacs got quasi freeze
  Message-ID : <3876ce8f-bbdb-ccbb-815b-c61e4133f1a8 <at> gmx.at>
  Date & Time: Tue, 24 Aug 2021 16:14:37 +0200

[RM] == martin rudalics <rudalics <at> gmx.at> has written:

RM>  [1  <text/plain; utf-8 (7bit)>]
RM>  > Sorry, but without avail.

RM>  One escalation more.

RM>  martin
RM>  [2 enlightenment.diff <text/x-patch (quoted-printable)>]
RM>  diff --git a/src/termhooks.h b/src/termhooks.h
RM>  index 1d3cdc8fe8..479b8a1c29 100644
RM>  --- a/src/termhooks.h
RM>  +++ b/src/termhooks.h
RM>  @@ -168,7 +168,8 @@ #define EMACS_TERMHOOKS_H
RM>   				   Lisp-level event value.
RM>   				   (Only the toolkit version uses these.)  */
RM>     ICONIFY_EVENT,		/* An X client iconified this window.  */
[...]
RM>  +	  XSETFRAME (inev.ie.frame_or_window, f);
RM>  +	}

RM>         goto OTHER;

Sorry, but still without avail.

Thanks.

---
┏━━┓彡     Masaru Nomiya              mail-to: nomiya @ galaxy.dti.ne.jp
┃\/彡
┗━━┛ "Tim Cook, the C.E.O. of Apple, said earlier this year that he would
	   not let his nephew join social networks. Bill Gates banned cellphone
	   until his children were teenagers, and Melinda Gates wrote that she
	   wished they had waited even longer. Steve Jobs would not let his young
	   children near iPads."
--'A Dark Consensus About Screens and Kids Begins to Emerge in Silicon Valley' -
The New York Times --




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Wed, 25 Aug 2021 14:17:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: m.nomiya <at> gmail.com, 49959 <at> debbugs.gnu.org
Subject: Re: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Wed, 25 Aug 2021 16:16:33 +0200
> Sorry, but still without avail.

Then we have to dig deeper.  For this purpose please proceed as follows
with emacs -Q:

(1) Evaluate the form (setq frame-size-history '(100))

(2) Switch to another virtual desktop and back.

(3) Do C-g or whatever you need to make that frame accessible

(4) Evaluate the form (frame--size-history)

(5) Post the contents of the buffer named *frame-size-history* here

Thanks, martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Thu, 26 Aug 2021 00:26:01 GMT) Full text and rfc822 format available.

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

From: Masaru Nomiya <nomiya <at> galaxy.dti.ne.jp>
To: 49959 <at> debbugs.gnu.org
Subject: Re: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Thu, 26 Aug 2021 09:24:57 +0900
Hello,

In the Message; 

  Subject    : bug#49959: 28.0.50; Emacs got quasi freeze
  Message-ID : <efb0856c-a7f7-3023-f00a-7fbe9271dd4d <at> gmx.at>
  Date & Time: Wed, 25 Aug 2021 16:16:33 +0200

[RM] == martin rudalics <rudalics <at> gmx.at> has written:

RM>  > Sorry, but still without avail.

RM>  Then we have to dig deeper.  For this purpose please proceed as follows
RM>  with emacs -Q:

RM>  (1) Evaluate the form (setq frame-size-history '(100))

RM>  (2) Switch to another virtual desktop and back.

RM>  (3) Do C-g or whatever you need to make that frame accessible

RM>  (4) Evaluate the form (frame--size-history)

RM>  (5) Post the contents of the buffer named *frame-size-history* here

1. for the emacs with bug

Frame size history of #<frame *scratch* - GNU Emacs at linux-egwc 0x1654540>
set_window_configuration (4), MS=140x150 IH IV

2. for the emacs without bug

Frame size history of #<frame *scratch* - GNU Emacs at linux-egwc 0x25c2540>
x_make_frame_visible
set_window_configuration (4), MS=140x150 IH IV

Thanks.

---
┏━━┓彡 Masaru Nomiya             mail-to: nomiya @ galaxy.dti.ne.jp
┃\/彡
┗━━┛ "Three young men died for Rationalization.
           Yet, Margaret Bloody Thatcher LIVES!"
                                            'Brassed Off'




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Thu, 26 Aug 2021 07:54:01 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: m.nomiya <at> gmail.com, 49959 <at> debbugs.gnu.org
Subject: Re: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Thu, 26 Aug 2021 09:52:54 +0200
> 1. for the emacs with bug
>
> Frame size history of #<frame *scratch* - GNU Emacs at linux-egwc 0x1654540>
> set_window_configuration (4), MS=140x150 IH IV
>
> 2. for the emacs without bug
>
> Frame size history of #<frame *scratch* - GNU Emacs at linux-egwc 0x25c2540>
> x_make_frame_visible
> set_window_configuration (4), MS=140x150 IH IV

One interesting aspect is that apparently in neither case we are
notified that our frame gets hidden when switching desktops.

Please do the following:

- Try again with the latest patch I sent you.

- Send me a diff of your "emacs with bug" and your "emacs without bug".

And, if possible, run the version "without bug" under GDB and post a
backtrace from a position where it produces the "x_make_frame_visible"
line, somewhere around here in xterm.c:

    if (!FRAME_VISIBLE_P (f))
      {
	if (CONSP (frame_size_history))
	  frame_size_history_plain
	    (f, build_string ("x_make_frame_visible"));

	x_wait_for_event (f, MapNotify);
      }

I cannot imagine how Emacs can get there without producing any recorded
events before or after it so it would be very interesting to find out
how it got there in the first place.

Thanks, martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Sun, 29 Aug 2021 02:06:01 GMT) Full text and rfc822 format available.

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

From: Masaru Nomiya <nomiya <at> galaxy.dti.ne.jp>
To: 49959 <at> debbugs.gnu.org
Subject: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Sun, 29 Aug 2021 11:05:14 +0900
Hello,

Sorry for late reply.

I's a hard work for me. :-)

In the Message; 

  Subject    : bug#49959: 28.0.50; Emacs got quasi freeze
  Message-ID : <bb2698b1-0f95-b661-f40a-8cb8dad20807 <at> gmx.at>
  Date & Time: Thu, 26 Aug 2021 09:52:54 +0200

[RM] == martin rudalics <rudalics <at> gmx.at> has written:

MN> > 1. for the emacs with bug

MN> > Frame size history of #<frame *scratch* - GNU Emacs at linux-egwc 0x1654540>
MN> > set_window_configuration (4), MS=140x150 IH IV

MN> > 2. for the emacs without bug
MN> >
MN> > Frame size history of #<frame *scratch* - GNU Emacs at linux-egwc 0x25c2540>
MN> > x_make_frame_visible
MN> > set_window_configuration (4), MS=140x150 IH IV

RM>  One interesting aspect is that apparently in neither case we are
RM>  notified that our frame gets hidden when switching desktops.

RM>  Please do the following:

RM>  - Try again with the latest patch I sent you.

RM>  - Send me a diff of your "emacs with bug" and your "emacs without bug".

1. for emacs without bug

Frame size history of #<frame *scratch* - GNU Emacs at linux-egwc 0x55627cc9d400>
x_make_frame_visible
set_window_configuration (4), MS=140x150 IH IV 

2. for patched emacs

Frame size history of #<frame *scratch* - GNU Emacs at linux-egwc 0x5580c551de00>
set_window_configuration (4), MS=140x150 IH IV

RM>  And, if possible, run the version "without bug" under GDB and post a
RM>  backtrace from a position where it produces the "x_make_frame_visible"
RM>  line, somewhere around here in xterm.c:

RM>      if (!FRAME_VISIBLE_P (f))
RM>        {
RM>  	if (CONSP (frame_size_history))
RM>  	  frame_size_history_plain
RM>  	    (f, build_string ("x_make_frame_visible"));

RM>  	x_wait_for_event (f, MapNotify);
RM>        }

RM>  I cannot imagine how Emacs can get there without producing any recorded
RM>  events before or after it so it would be very interesting to find out
RM>  how it got there in the first place.

This one?

(gdb) bt
#0  builtin_lisp_symbol (index=0) at lisp.h:1008
#1  0x0000000000573854 in x_make_frame_visible (f=0x12815e8) at xterm.c:11686
#2  0x0000000000574044 in x_make_frame_visible_invisible
    (f=0x12815e8, visible=true) at xterm.c:11898
#3  0x000000000043bf11 in Fmake_frame_visible (frame=0x12815ed) at frame.c:2718
#4  0x000000000068f99d in funcall_subr
    (subr=0xe571c0 <Smake_frame_visible>, numargs=1, args=0x7fffffffa250)
    at eval.c:3126
#5  0x000000000068f47e in Ffuncall (nargs=2, args=0x7fffffffa248)
    at eval.c:3051
#6  0x00000000006e73d5 in exec_byte_code
    (bytestr=0x7fffda3a1a14, vector=0x7fffda3a0685, maxdepth=0x2e, args_template=0x402, nargs=1, args=0x7fffffffa7c0) at bytecode.c:632
#7  0x000000000068fc50 in fetch_and_exec_byte_code
    (fun=0x7fffda3a0655, syms_left=0x402, nargs=1, args=0x7fffffffa7b8)
    at eval.c:3175
#8  0x00000000006900c2 in funcall_lambda
    (fun=0x7fffda3a0655, nargs=1, arg_vector=0x7fffffffa7b8) at eval.c:3256
#9  0x000000000068f4d2 in Ffuncall (nargs=2, args=0x7fffffffa7b0)
--Type <RET> for more, q to quit, c to continue without paging--
    at eval.c:3055
#10 0x00000000006e73d5 in exec_byte_code
    (bytestr=0x7fffda3a1ad4, vector=0x7fffda3a0615, maxdepth=0xe, args_template=0x406, nargs=1, args=0x7fffffffae00) at bytecode.c:632
#11 0x000000000068fc50 in fetch_and_exec_byte_code
    (fun=0x7fffda3a05c5, syms_left=0x406, nargs=1, args=0x7fffffffadf8)
    at eval.c:3175
#12 0x00000000006900c2 in funcall_lambda
    (fun=0x7fffda3a05c5, nargs=1, arg_vector=0x7fffffffadf8) at eval.c:3256
#13 0x000000000068f4d2 in Ffuncall (nargs=2, args=0x7fffffffadf0)
    at eval.c:3055
#14 0x000000000068e1fb in Fapply (nargs=2, args=0x7fffffffadf0) at eval.c:2638
#15 0x000000000068f8a8 in funcall_subr
    (subr=0xe652c0 <Sapply>, numargs=2, args=0x7fffffffadf0) at eval.c:3106
#16 0x000000000068f47e in Ffuncall (nargs=3, args=0x7fffffffade8)
    at eval.c:3051
#17 0x00000000006e73d5 in exec_byte_code
    (bytestr=0x7fffd9ffb5c4, vector=0x7fffda06106d, maxdepth=0x3e, args_template=0x202, nargs=1, args=0x7fffffffb358) at bytecode.c:632
--Type <RET> for more, q to quit, c to continue without paging--
#18 0x000000000068fc50 in fetch_and_exec_byte_code
    (fun=0x7fffda06103d, syms_left=0x202, nargs=1, args=0x7fffffffb358)
    at eval.c:3175
#19 0x00000000006900c2 in funcall_lambda
    (fun=0x7fffda06103d, nargs=1, arg_vector=0x7fffffffb358) at eval.c:3256
#20 0x000000000068f4d2 in Ffuncall (nargs=2, args=0x7fffffffb350)
    at eval.c:3055
#21 0x00000000006e73d5 in exec_byte_code
    (bytestr=0x7fffda38f9c4, vector=0x7fffda07505d, maxdepth=0x3a, args_template=0x402, nargs=1, args=0x7fffffffb948) at bytecode.c:632
#22 0x000000000068fc50 in fetch_and_exec_byte_code
    (fun=0x7fffda075025, syms_left=0x402, nargs=1, args=0x7fffffffb940)
    at eval.c:3175
#23 0x00000000006900c2 in funcall_lambda
    (fun=0x7fffda075025, nargs=1, arg_vector=0x7fffffffb940) at eval.c:3256
#24 0x000000000068f4d2 in Ffuncall (nargs=2, args=0x7fffffffb938)
    at eval.c:3055
#25 0x00000000006e73d5 in exec_byte_code
    (bytestr=0x7fffda1842d4, vector=0x7fffda183fcd, maxdepth=0x1a, args_template--Type <RET> for more, q to quit, c to continue without paging--
=0x2, nargs=0, args=0x7fffffffbe60) at bytecode.c:632
#26 0x000000000068fc50 in fetch_and_exec_byte_code
    (fun=0x7fffda183f9d, syms_left=0x2, nargs=0, args=0x7fffffffbe60)
    at eval.c:3175
#27 0x00000000006900c2 in funcall_lambda
    (fun=0x7fffda183f9d, nargs=0, arg_vector=0x7fffffffbe60) at eval.c:3256
#28 0x000000000068f4d2 in Ffuncall (nargs=1, args=0x7fffffffbe58)
    at eval.c:3055
#29 0x00000000006e73d5 in exec_byte_code
    (bytestr=0x7fffda188124, vector=0x7fffda174cb5, maxdepth=0x3a, args_template=0x2, nargs=0, args=0x7fffffffc918) at bytecode.c:632
#30 0x000000000068fc50 in fetch_and_exec_byte_code
    (fun=0x7fffda174c85, syms_left=0x2, nargs=0, args=0x7fffffffc918)
    at eval.c:3175
#31 0x00000000006900c2 in funcall_lambda
    (fun=0x7fffda174c85, nargs=0, arg_vector=0x7fffffffc918) at eval.c:3256
#32 0x000000000068f4d2 in Ffuncall (nargs=1, args=0x7fffffffc910)
    at eval.c:3055
#33 0x00000000006e73d5 in exec_byte_code
--Type <RET> for more, q to quit, c to continue without paging--
    (bytestr=0x7fffda18a49c, vector=0x7fffda17429d, maxdepth=0x26, args_template=0x2, nargs=0, args=0x7fffffffcfe0) at bytecode.c:632
#34 0x000000000068fc50 in fetch_and_exec_byte_code
    (fun=0x7fffda17426d, syms_left=0x2, nargs=0, args=0x7fffffffcfe0)
    at eval.c:3175
#35 0x00000000006900c2 in funcall_lambda
    (fun=0x7fffda17426d, nargs=0, arg_vector=0x7fffffffcfe0) at eval.c:3256
#36 0x000000000068fdfa in apply_lambda (fun=0x7fffda17426d, args=0x0, count=4)
    at eval.c:3200
#37 0x000000000068de35 in eval_sub (form=0x7fffda6afbeb) at eval.c:2573
#38 0x000000000068d1d3 in Feval (form=0x7fffda6afbeb, lexical=0x0)
    at eval.c:2355
#39 0x00000000005b4856 in top_level_2 () at keyboard.c:1126
#40 0x000000000068af6d in internal_condition_case
    (bfun=0x5b4833 <top_level_2>, handlers=0x90, hfun=0x5b4100 <cmd_error>)
    at eval.c:1478
#41 0x00000000005b489a in top_level_1 (ignore=0x0) at keyboard.c:1134
#42 0x000000000068a1c2 in internal_catch
    (tag=0xe730, func=0x5b4858 <top_level_1>, arg=0x0) at eval.c:1198
--Type <RET> for more, q to quit, c to continue without paging--
#43 0x00000000005b478b in command_loop () at keyboard.c:1094
#44 0x00000000005b3be1 in recursive_edit_1 () at keyboard.c:720
#45 0x00000000005b3deb in Frecursive_edit () at keyboard.c:792
#46 0x00000000005afea6 in main (argc=1, argv=0x7fffffffd568) at emacs.c:2310

---
┏━━┓彡 Masaru Nomiya             mail-to: nomiya @ galaxy.dti.ne.jp
┃\/彡
┗━━┛ "Bill! You married with Computer.
          Not with Me!"
         "No..., with money."




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Sun, 29 Aug 2021 07:23:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: m.nomiya <at> gmail.com, 49959 <at> debbugs.gnu.org
Subject: Re: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Sun, 29 Aug 2021 09:21:59 +0200
> RM>  - Send me a diff of your "emacs with bug" and your "emacs without bug".

Sorry but what I meant here is that you should send me the output of the
diff program for the codes, that is the differences when comparing the
_code_ of the "emacs without bug" and the _code_ of "emacs with bug".  I
cannot guess that from here because I cannot simply revert commit
483c5e953c12a95382bef4a3b6769a680c32fe86 here - it gets me a conflict
with a later commit.

When you send me the differences between the two versions, I hopefully
will be able to figure out why they behave differently when run.  So
please don't _run_ emacs for this purpose but tell me what the static
differences between these two versions are.  And don't hesitate to ask
if this request was unclear again.

> RM>  I cannot imagine how Emacs can get there without producing any recorded
> RM>  events before or after it so it would be very interesting to find out
> RM>  how it got there in the first place.
>
> This one?
>
> (gdb) bt
> #0  builtin_lisp_symbol (index=0) at lisp.h:1008
> #1  0x0000000000573854 in x_make_frame_visible (f=0x12815e8) at xterm.c:11686
> #2  0x0000000000574044 in x_make_frame_visible_invisible
>      (f=0x12815e8, visible=true) at xterm.c:11898
> #3  0x000000000043bf11 in Fmake_frame_visible (frame=0x12815ed) at frame.c:2718
> #4  0x000000000068f99d in funcall_subr
>      (subr=0xe571c0 <Smake_frame_visible>, numargs=1, args=0x7fffffffa250)
>      at eval.c:3126
> #5  0x000000000068f47e in Ffuncall (nargs=2, args=0x7fffffffa248)
>      at eval.c:3051
[...]
> #39 0x00000000005b4856 in top_level_2 () at keyboard.c:1126
> #40 0x000000000068af6d in internal_condition_case
>      (bfun=0x5b4833 <top_level_2>, handlers=0x90, hfun=0x5b4100 <cmd_error>)
>      at eval.c:1478
> #41 0x00000000005b489a in top_level_1 (ignore=0x0) at keyboard.c:1134
> #42 0x000000000068a1c2 in internal_catch
>      (tag=0xe730, func=0x5b4858 <top_level_1>, arg=0x0) at eval.c:1198
> --Type <RET> for more, q to quit, c to continue without paging--
> #43 0x00000000005b478b in command_loop () at keyboard.c:1094
> #44 0x00000000005b3be1 in recursive_edit_1 () at keyboard.c:720
> #45 0x00000000005b3deb in Frecursive_edit () at keyboard.c:792
> #46 0x00000000005afea6 in main (argc=1, argv=0x7fffffffd568) at emacs.c:2310

This one, right.  It still leaves me with the mystery that
`frame-size-history' does not record a single event whenever you switch
desktops.

Thanks, martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Tue, 31 Aug 2021 16:52:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: m.nomiya <at> gmail.com, 49959 <at> debbugs.gnu.org
Subject: Re: Diff file (Was: Re: bug#49959: 28.0.50; Emacs got quasi freeze)
Date: Tue, 31 Aug 2021 18:51:35 +0200
[Message part 1 (text/plain, inline)]
> The problem maybe be fixed, I feel.
>
> Sorry, I don't know the confirming method.
> But, I've never got the rendering issue since applying your patch.
>
> Is this fine?

Hopefully.  It doesn't break the behavior under xfce/xfwm4.  I yet have
to test with Gnome and Plasma.  Meanwhile please do the following:

Apply the attached patch which adds a few diagnostics.  Then evaluate

  (setq frame-size-history '(100))

switch to the other virtual desktop, switch back to the Emacs
desktop, evaluate

  (frame--size-history frame)
  (pop-to-buffer "*frame-size-history*")

and tell me what *frame-size-history* contains now.

Then please do the same with Emacs _not_ focused before switching to the
other desktop.

And please also try the following: With emacs -Q put into *scratch*
the lines

(setq frame (make-frame))
(frame-visible-p frame)
(make-frame-invisible frame)
(make-frame-visible frame)
(iconify-frame frame)

Now use C-x C-e after any of these forms to first make FRAME and, for
example, make FRAME invisible, then make it iconified, then make it
visible and so on.  After every step use the `frame-visible-p' form to
check what Emacs thinks FRAME is.  If you find a transition that you
think is not correct, please tell me.

Thanks again, martin
[FocusIn.diff (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Wed, 01 Sep 2021 00:22:01 GMT) Full text and rfc822 format available.

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

From: Masaru Nomiya <nomiya <at> galaxy.dti.ne.jp>
To: rudalics <at> gmx.at
Cc: 49959 <at> debbugs.gnu.org
Subject: Re: bug#49959: Diff file (Was: Re: bug#49959: 28.0.50;
 Emacs got quasi freeze)
Date: Wed, 01 Sep 2021 09:21:14 +0900
Hello,

In the Message; 

  Subject    : bug#49959: Diff file (Was: Re: bug#49959: 28.0.50; Emacs got quasi freeze)
  Message-ID : <6e2372de-749c-889d-98a5-45da734d3d1c <at> gmx.at>
  Date & Time: Tue, 31 Aug 2021 18:51:35 +0200

[MR] == martin rudalics <rudalics <at> gmx.at> has written:

MN> > The problem maybe be fixed, I feel.
MN> >
MN> > Sorry, I don't know the confirming method.
MN> > But, I've never got the rendering issue since applying your patch.
MN> >
MN> > Is this fine?

MR>  Hopefully.  It doesn't break the behavior under xfce/xfwm4.  I yet have
MR>  to test with Gnome and Plasma.  Meanwhile please do the following:

MR>  Apply the attached patch which adds a few diagnostics.  Then evaluate

MR>    (setq frame-size-history '(100))

MR>  switch to the other virtual desktop, switch back to the Emacs
MR>  desktop, evaluate

MR>    (frame--size-history frame)
MR>    (pop-to-buffer "*frame-size-history*")

MR>  and tell me what *frame-size-history* contains now.

#<buffer *frame-size-history*>

MR>  Then please do the same with Emacs _not_ focused before switching to the
MR>  other desktop.

MR>  And please also try the following: With emacs -Q put into *scratch*
MR>  the lines

MR>  (setq frame (make-frame))
MR>  (frame-visible-p frame)
MR>  (make-frame-invisible frame)
MR>  (make-frame-visible frame)
MR>  (iconify-frame frame)

MR>  Now use C-x C-e after any of these forms to first make FRAME and, for
MR>  example, make FRAME invisible, then make it iconified, then make it
MR>  visible and so on.  After every step use the `frame-visible-p' form to
MR>  check what Emacs thinks FRAME is.  If you find a transition that you
MR>  think is not correct, please tell me.

The transition is corrext, and FRAME is *scratch*.

Thanks.

---
┏━━┓彡 Masaru Nomiya             mail-to: nomiya @ galaxy.dti.ne.jp
┃\/彡
┗━━┛ "Bill! You married with Computer.
          Not with Me!"
         "No..., with money."




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Wed, 01 Sep 2021 09:18:01 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: m.nomiya <at> gmail.com
Cc: 49959 <at> debbugs.gnu.org
Subject: Re: bug#49959: Diff file (Was: Re: bug#49959: 28.0.50; Emacs got
 quasi freeze)
Date: Wed, 1 Sep 2021 11:17:27 +0200
> MR>  Hopefully.  It doesn't break the behavior under xfce/xfwm4.  I yet have
> MR>  to test with Gnome and Plasma.  Meanwhile please do the following:
>
> MR>  Apply the attached patch which adds a few diagnostics.  Then evaluate
>
> MR>    (setq frame-size-history '(100))
>
> MR>  switch to the other virtual desktop, switch back to the Emacs
> MR>  desktop, evaluate
>
> MR>    (frame--size-history frame)
                              ^^^^^
This was a bug on my side ...

> MR>    (pop-to-buffer "*frame-size-history*")
>
> MR>  and tell me what *frame-size-history* contains now.
>
> #<buffer *frame-size-history*>

... so please try again with:

Then evaluate

  (setq frame-size-history '(100))

switch to the other virtual desktop, switch back to the Emacs
desktop, evaluate

  (frame--size-history)
  (pop-to-buffer "*frame-size-history*")

and tell me what *frame-size-history* contains now.

> MR>  And please also try the following: With emacs -Q put into *scratch*
> MR>  the lines
>
> MR>  (setq frame (make-frame))
> MR>  (frame-visible-p frame)
> MR>  (make-frame-invisible frame)
> MR>  (make-frame-visible frame)
> MR>  (iconify-frame frame)
>
> MR>  Now use C-x C-e after any of these forms to first make FRAME and, for
> MR>  example, make FRAME invisible, then make it iconified, then make it
> MR>  visible and so on.  After every step use the `frame-visible-p' form to
> MR>  check what Emacs thinks FRAME is.

Silly me again: I meant "what Emacs thinks in what state FRAME is"
namely, not visible (nil), iconified (icon), or visible (t).

> If you find a transition that you
> MR>  think is not correct, please tell me.
>
> The transition is corrext, and FRAME is *scratch*.

I meanwhile got around installing Enlightenment here and note that I
cannot deiconify a frame via

(iconify-frame frame)
(make-frame-visible frame)

The frame stays iconified.  Can you confirm?  I see the same behavior
with GNOME shell - so maybe this is expected and was so ever since.

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Wed, 01 Sep 2021 10:06:02 GMT) Full text and rfc822 format available.

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

From: Masaru Nomiya <nomiya <at> galaxy.dti.ne.jp>
To: 49959 <at> debbugs.gnu.org
Subject: bug#49959: Diff file (Was: Re: bug#49959: 28.0.50;
 Emacs got quasi freeze)
Date: Wed, 01 Sep 2021 19:05:20 +0900
Hello,

In the Message; 

  Subject    : bug#49959: Diff file (Was: Re: bug#49959: 28.0.50; Emacs got quasi freeze)
  Message-ID : <c488002b-a106-5634-9835-201a63aa3d35 <at> gmx.at>
  Date & Time: Wed, 1 Sep 2021 11:17:27 +0200

[MR] == martin rudalics <rudalics <at> gmx.at> has written:

[...]
MR>  ... so please try again with:

MR>  Then evaluate

MR>    (setq frame-size-history '(100))

MR>  switch to the other virtual desktop, switch back to the Emacs
MR>  desktop, evaluate

MR>    (frame--size-history)
MR>    (pop-to-buffer "*frame-size-history*")

MR>  and tell me what *frame-size-history* contains now.

Here it is.

Frame size history of #<frame *scratch* - GNU Emacs at linux-egwc 0x2b24880>
set_window_configuration (4), MS=140x150 IH IV
Expose, visible
#<buffer *frame-size-history*>

[...]
MR>>> If you find a transition that you
MR>>>  think is not correct, please tell me.

MN> > The transition is corrext, and FRAME is *scratch*.

MR>  I meanwhile got around installing Enlightenment here and note that I
MR>  cannot deiconify a frame via

MR>  (iconify-frame frame)
MR>  (make-frame-visible frame)

MR>  The frame stays iconified.  Can you confirm? 

Yes, I can confirm it.

MR> I see the same behavior with GNOME shell - so maybe this is
MR> expected and was so ever since.

Is it?

Anyway, thanks.

---
┏━━┓彡 Masaru Nomiya             mail-to: nomiya @ galaxy.dti.ne.jp
┃\/彡
┗━━┛ "No Windows, no gains!" ..... "Why, I am wrong?"
        
                                          -- Bill --




Removed tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Wed, 01 Sep 2021 11:12:01 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Mon, 22 Aug 2022 12:01:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Masaru Nomiya <nomiya <at> galaxy.dti.ne.jp>
Cc: martin rudalics <rudalics <at> gmx.at>, 49959 <at> debbugs.gnu.org,
 m.nomiya <at> gmail.com
Subject: Re: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Mon, 22 Aug 2022 13:59:48 +0200
Masaru Nomiya <nomiya <at> galaxy.dti.ne.jp> writes:

> MR>  I meanwhile got around installing Enlightenment here and note that I
> MR>  cannot deiconify a frame via
>
> MR>  (iconify-frame frame)
> MR>  (make-frame-visible frame)
>
> MR>  The frame stays iconified.  Can you confirm? 
>
> Yes, I can confirm it.
>
> MR> I see the same behavior with GNOME shell - so maybe this is
> MR> expected and was so ever since.
>
> Is it?

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

This was almost a year ago -- do you still see these issues in Emacs 29?




Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 22 Aug 2022 12:01:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Mon, 19 Sep 2022 19:20:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Masaru Nomiya <nomiya <at> galaxy.dti.ne.jp>
Cc: martin rudalics <rudalics <at> gmx.at>, 49959 <at> debbugs.gnu.org,
 m.nomiya <at> gmail.com
Subject: Re: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Mon, 19 Sep 2022 21:19:06 +0200
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> This was almost a year ago -- do you still see these issues in Emacs 29?

More information was requested, but no response was given within a
month, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.




bug closed, send any further explanations to 49959 <at> debbugs.gnu.org and 野宮 賢 / NOMIYA Masaru <m.nomiya <at> gmail.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 19 Sep 2022 19:20:03 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#49959; Package emacs. (Mon, 19 Sep 2022 21:48:02 GMT) Full text and rfc822 format available.

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

From: 野宮 賢 / NOMIYA Masaru
 <nomiya <at> galaxy.dti.ne.jp>
To: larsi <at> gnus.org, rudalics <at> gmx.at, 49959 <at> debbugs.gnu.org
Subject: Re: bug#49959: 28.0.50; Emacs got quasi freeze
Date: Tue, 20 Sep 2022 06:45:43 +0900
Hello,

In the Message; 

  Subject    : Re: bug#49959: 28.0.50; Emacs got quasi freeze
  Message-ID : <87a66vqij9.fsf <at> gnus.org>
  Date & Time: Mon, 19 Sep 2022 21:19:06 +0200

[LMI] == Lars Ingebrigtsen <larsi <at> gnus.org> has written:

LMI>  Lars Ingebrigtsen <larsi <at> gnus.org> writes:

LMI>> This was almost a year ago -- do you still see these issues in Emacs 29?

LMI>  More information was requested, but no response was given within a
LMI>  month, so I'm closing this bug report.  If the problem still exists,
LMI>  please respond to this email and we'll reopen the bug report.

Sorry for too late reply.

I recognised your email from the fetchmail logs;

  $> cat from-log | grep -B 2 /null
  From larsi <at> gnus.org  Tue Sep 20 05:51:15 2022
  Subject: Re: bug#49959: 28.0.50; Emacs got quasi freeze
  Folder: /dev/null

So I looked on the gmail server and found it in my spam folder.

I think that other emails with the same Message-ID were caught by a
filter setting that sent them to /dev/null.

By the way, thanks to you, the problem (bug#49959)  has been solved,
now.

Regards.

---
┏━━┓彡   Masaru Nomiya                   mail-to: nomiya @ galaxy.dti.ne.jp
┃\/彡
┗━━┛       " Today’s China is not the old China humiliated and bullied over
	       100 years ago. It is time for these people to wake up from their
	       imperial dream."

              -- Hua Chunying’s Regular Press Conference on August 4, 2022 -- 




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

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

Previous Next


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