bug#49959: 28.0.50; Emacs got quasi freeze

bug#49959: 28.0.50; Emacs got quasi freeze

[野宮 賢 / NOMIYA Masaru]

Hello.

With this pacth;

commit 483c5e953c12a95382bef4a3b6769a680c32fe86
Author: Martin Rudalics <rudalics@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'

bug#49959: 28.0.50; Emacs got quasi freeze

[martin rudalics]

 > With this pacth;
 >
 > commit 483c5e953c12a95382bef4a3b6769a680c32fe86
 > Author: Martin Rudalics <rudalics@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

bug#49959: 28.0.50; Emacs got quasi freeze

[Masaru Nomiya]

Hello,

In the Message; 

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

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

MN> > With this pacth;

MN> > commit 483c5e953c12a95382bef4a3b6769a680c32fe86
MN> > Author: Martin Rudalics <rudalics@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."

bug#49959: 28.0.50; Emacs got quasi freeze

[Masaru Nomiya]

Hello,

In the Message; 

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

[MN] == Masaru Nomiya <nomiya@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@gmx.at>
MN>   Date & Time: Wed, 18 Aug 2021 10:03:50 +0200

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

MN> > With this pacth;

MN> > commit 483c5e953c12a95382bef4a3b6769a680c32fe86
MN> > Author: Martin Rudalics <rudalics@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@rasterman.com>
  Date & Time: Sat, 21 Aug 2021 07:23:03 +0100

[Dev] == Dev <xxxx@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'

bug#49959: 28.0.50; Emacs got quasi freeze

[martin rudalics]

 > 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@rasterman.com>
 >    Date & Time: Sat, 21 Aug 2021 07:23:03 +0100
 >
 > [Dev] == Dev <xxxx@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

bug#49959: 28.0.50; Emacs got quasi freeze

[martin rudalics]

 > 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

bug#49959: 28.0.50; Emacs got quasi freeze

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 624 bytes --]

 > 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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: deiconify.diff --]
[-- Type: text/x-patch; name="deiconify.diff", Size: 4348 bytes --]

diff --git a/src/termhooks.h b/src/termhooks.h
index 1d3cdc8fe8..479b8a1c29 100644
--- a/src/termhooks.h
+++ b/src/termhooks.h
@@ -168,7 +168,8 @@ #define EMACS_TERMHOOKS_H
 				   Lisp-level event value.
 				   (Only the toolkit version uses these.)  */
   ICONIFY_EVENT,		/* An X client iconified this window.  */
-  DEICONIFY_EVENT,		/* An X client deiconified this window.  */
+  DEICONIFY_EVENT,		/* An X client deiconified this window
+				   or made it visible.  */
   MENU_BAR_ACTIVATE_EVENT,      /* A button press in the menu bar
 				   (toolkit version only).  */
   DRAG_N_DROP_EVENT,		/* A drag-n-drop event is generated when
diff --git a/src/xterm.c b/src/xterm.c
index 6c6a62adb2..a4958c39de 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -8166,22 +8166,18 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       f = x_top_window_to_frame (dpyinfo, event->xproperty.window);
       if (f && event->xproperty.atom == dpyinfo->Xatom_net_wm_state)
 	{
+	  bool was_iconified = FRAME_ICONIFIED_P (f);
           bool not_hidden = x_handle_net_wm_state (f, &event->xproperty);

-	  if (not_hidden && FRAME_ICONIFIED_P (f))
+	  if (not_hidden)
 	    {
 	      if (CONSP (frame_size_history))
 		frame_size_history_plain
-		  (f, build_string ("PropertyNotify, not hidden & iconified"));
+		  (f, build_string ("PropertyNotify, not hidden"));

-	      /* Gnome shell does not iconify us when C-z is pressed.
-		 It hides the frame.  So if our state says we aren't
-		 hidden anymore, treat it as deiconified.  */
 	      SET_FRAME_VISIBLE (f, 1);
-	      SET_FRAME_ICONIFIED (f, false);
-
 	      f->output_data.x->has_been_visible = true;
-	      inev.ie.kind = DEICONIFY_EVENT;
+
 #if defined USE_GTK && defined HAVE_GTK3
 	      /* If GTK3 wants to impose some old size here (Bug#24526),
 		 tell it that the current size is what we want.  */
@@ -8192,18 +8188,27 @@ handle_one_xevent (struct x_display_info *dpyinfo,
 		  f->was_invisible = false;
 		}
 #endif
-	      XSETFRAME (inev.ie.frame_or_window, f);
+	      if (was_iconified)
+		{
+		  SET_FRAME_ICONIFIED (f, false);
+		  inev.ie.kind = DEICONIFY_EVENT;
+		  XSETFRAME (inev.ie.frame_or_window, f);
+		}
 	    }
-	  else if (!not_hidden && !FRAME_ICONIFIED_P (f))
+	  else
 	    {
 	      if (CONSP (frame_size_history))
 		frame_size_history_plain
-		  (f, build_string ("PropertyNotify, hidden & not iconified"));
+		  (f, build_string ("PropertyNotify, hidden"));

 	      SET_FRAME_VISIBLE (f, 0);
-	      SET_FRAME_ICONIFIED (f, true);
-	      inev.ie.kind = ICONIFY_EVENT;
-	      XSETFRAME (inev.ie.frame_or_window, f);
+
+	      if (!was_iconified)
+		{
+		  SET_FRAME_ICONIFIED (f, true);
+		  inev.ie.kind = ICONIFY_EVENT;
+		  XSETFRAME (inev.ie.frame_or_window, f);
+		}
 	    }
 	}

@@ -8402,7 +8407,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       f = x_top_window_to_frame (dpyinfo, event->xmap.window);
       if (f)
         {
-	  bool iconified = FRAME_ICONIFIED_P (f);
+	  bool was_iconified = FRAME_ICONIFIED_P (f);
 	  int value;
 	  bool sticky;
           bool not_hidden = x_get_current_wm_state (f, event->xmap.window, &value, &sticky);
@@ -8410,7 +8415,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
 	  if (CONSP (frame_size_history))
 	    frame_size_history_extra
 	      (f,
-	       iconified
+	       was_iconified
 	       ? (not_hidden
 		  ? build_string ("MapNotify, not hidden & iconified")
 		  : build_string ("MapNotify, hidden & iconified"))
@@ -8434,7 +8439,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
 #endif /* Not USE_GTK */
 	    }

-	  if (!iconified)
+	  if (!was_iconified)
 	    {
 	      /* The `z-group' is reset every time a frame becomes
 		 invisible.  Handle this here.  */
@@ -8459,13 +8464,13 @@ handle_one_xevent (struct x_display_info *dpyinfo,
 		}
 #endif
 	      f->output_data.x->has_been_visible = true;
-	    }

-          if (not_hidden && iconified)
-            {
-              inev.ie.kind = DEICONIFY_EVENT;
-              XSETFRAME (inev.ie.frame_or_window, f);
-            }
+	      if (was_iconified)
+		{
+		  inev.ie.kind = DEICONIFY_EVENT;
+		  XSETFRAME (inev.ie.frame_or_window, f);
+		}
+	    }
         }
       goto OTHER;

bug#49959: 28.0.50; Emacs got quasi freeze

[Masaru Nomiya]

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@gmx.at>
  Date & Time: Sun, 22 Aug 2021 18:54:11 +0200

[RM] == martin rudalics <rudalics@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 --

bug#49959: 28.0.50; Emacs got quasi freeze

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

 > 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

[-- Attachment #2: VisibilityNotify.diff --]
[-- Type: text/x-patch, Size: 548 bytes --]

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

       goto OTHER;

bug#49959: 28.0.50; Emacs got quasi freeze

[Masaru Nomiya]

Hello,

In the Message; 

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

[RM] == martin rudalics <rudalics@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'

bug#49959: 28.0.50; Emacs got quasi freeze

[Masaru Nomiya]

Hello,

In the Message; 

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

[MN] == Masaru Nomiya <nomiya@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@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'

bug#49959: 28.0.50; Emacs got quasi freeze

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 302 bytes --]

 > 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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: enlightenment.diff --]
[-- Type: text/x-patch; name="enlightenment.diff", Size: 5174 bytes --]

diff --git a/src/termhooks.h b/src/termhooks.h
index 1d3cdc8fe8..479b8a1c29 100644
--- a/src/termhooks.h
+++ b/src/termhooks.h
@@ -168,7 +168,8 @@ #define EMACS_TERMHOOKS_H
 				   Lisp-level event value.
 				   (Only the toolkit version uses these.)  */
   ICONIFY_EVENT,		/* An X client iconified this window.  */
-  DEICONIFY_EVENT,		/* An X client deiconified this window.  */
+  DEICONIFY_EVENT,		/* An X client deiconified this window
+				   or made it visible.  */
   MENU_BAR_ACTIVATE_EVENT,      /* A button press in the menu bar
 				   (toolkit version only).  */
   DRAG_N_DROP_EVENT,		/* A drag-n-drop event is generated when
diff --git a/src/xterm.c b/src/xterm.c
index 6c6a62adb2..82d2ae3a52 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -8166,22 +8166,19 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       f = x_top_window_to_frame (dpyinfo, event->xproperty.window);
       if (f && event->xproperty.atom == dpyinfo->Xatom_net_wm_state)
 	{
+	  bool was_iconified = FRAME_ICONIFIED_P (f);
           bool not_hidden = x_handle_net_wm_state (f, &event->xproperty);

-	  if (not_hidden && FRAME_ICONIFIED_P (f))
+	  if (not_hidden)
 	    {
 	      if (CONSP (frame_size_history))
 		frame_size_history_plain
-		  (f, build_string ("PropertyNotify, not hidden & iconified"));
+		  (f, build_string ("PropertyNotify, not hidden"));

-	      /* Gnome shell does not iconify us when C-z is pressed.
-		 It hides the frame.  So if our state says we aren't
-		 hidden anymore, treat it as deiconified.  */
+	      SET_FRAME_GARBAGED (f);
 	      SET_FRAME_VISIBLE (f, 1);
-	      SET_FRAME_ICONIFIED (f, false);
-
 	      f->output_data.x->has_been_visible = true;
-	      inev.ie.kind = DEICONIFY_EVENT;
+
 #if defined USE_GTK && defined HAVE_GTK3
 	      /* If GTK3 wants to impose some old size here (Bug#24526),
 		 tell it that the current size is what we want.  */
@@ -8192,18 +8189,27 @@ handle_one_xevent (struct x_display_info *dpyinfo,
 		  f->was_invisible = false;
 		}
 #endif
-	      XSETFRAME (inev.ie.frame_or_window, f);
+	      if (was_iconified)
+		{
+		  SET_FRAME_ICONIFIED (f, false);
+		  inev.ie.kind = DEICONIFY_EVENT;
+		  XSETFRAME (inev.ie.frame_or_window, f);
+		}
 	    }
-	  else if (!not_hidden && !FRAME_ICONIFIED_P (f))
+	  else
 	    {
 	      if (CONSP (frame_size_history))
 		frame_size_history_plain
-		  (f, build_string ("PropertyNotify, hidden & not iconified"));
+		  (f, build_string ("PropertyNotify, hidden"));

 	      SET_FRAME_VISIBLE (f, 0);
-	      SET_FRAME_ICONIFIED (f, true);
-	      inev.ie.kind = ICONIFY_EVENT;
-	      XSETFRAME (inev.ie.frame_or_window, f);
+
+	      if (!was_iconified)
+		{
+		  SET_FRAME_ICONIFIED (f, true);
+		  inev.ie.kind = ICONIFY_EVENT;
+		  XSETFRAME (inev.ie.frame_or_window, f);
+		}
 	    }
 	}

@@ -8402,7 +8408,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       f = x_top_window_to_frame (dpyinfo, event->xmap.window);
       if (f)
         {
-	  bool iconified = FRAME_ICONIFIED_P (f);
+	  bool was_iconified = FRAME_ICONIFIED_P (f);
 	  int value;
 	  bool sticky;
           bool not_hidden = x_get_current_wm_state (f, event->xmap.window, &value, &sticky);
@@ -8410,7 +8416,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
 	  if (CONSP (frame_size_history))
 	    frame_size_history_extra
 	      (f,
-	       iconified
+	       was_iconified
 	       ? (not_hidden
 		  ? build_string ("MapNotify, not hidden & iconified")
 		  : build_string ("MapNotify, hidden & iconified"))
@@ -8434,7 +8440,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
 #endif /* Not USE_GTK */
 	    }

-	  if (!iconified)
+	  if (!was_iconified)
 	    {
 	      /* The `z-group' is reset every time a frame becomes
 		 invisible.  Handle this here.  */
@@ -8459,13 +8465,13 @@ handle_one_xevent (struct x_display_info *dpyinfo,
 		}
 #endif
 	      f->output_data.x->has_been_visible = true;
-	    }

-          if (not_hidden && iconified)
-            {
-              inev.ie.kind = DEICONIFY_EVENT;
-              XSETFRAME (inev.ie.frame_or_window, f);
-            }
+	      if (was_iconified)
+		{
+		  inev.ie.kind = DEICONIFY_EVENT;
+		  XSETFRAME (inev.ie.frame_or_window, f);
+		}
+	    }
         }
       goto OTHER;

@@ -9354,7 +9360,21 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       f = x_top_window_to_frame (dpyinfo, event->xvisibility.window);
       if (f && (event->xvisibility.state == VisibilityUnobscured
 		|| event->xvisibility.state == VisibilityPartiallyObscured))
-	SET_FRAME_VISIBLE (f, 1);
+	{
+#if defined USE_GTK && defined HAVE_GTK3
+	  /* If GTK3 wants to impose some old size here (Bug#24526),
+	     tell it that the current size is what we want.  */
+	  if (f->was_invisible)
+	    {
+	      xg_frame_set_char_size
+		(f, FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f));
+	      f->was_invisible = false;
+	    }
+#endif
+	  f->output_data.x->has_been_visible = true;
+	  SET_FRAME_GARBAGED (f);
+	  SET_FRAME_VISIBLE (f, 1);
+	}

       goto OTHER;

bug#49959: 28.0.50; Emacs got quasi freeze

[Masaru Nomiya]

Hello,

In the Message; 

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

[RM] == martin rudalics <rudalics@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' --

bug#49959: 28.0.50; Emacs got quasi freeze

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 59 bytes --]

 > Sorry, but without avail.

One escalation more.

martin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: enlightenment.diff --]
[-- Type: text/x-patch; name="enlightenment.diff", Size: 5185 bytes --]

diff --git a/src/termhooks.h b/src/termhooks.h
index 1d3cdc8fe8..479b8a1c29 100644
--- a/src/termhooks.h
+++ b/src/termhooks.h
@@ -168,7 +168,8 @@ #define EMACS_TERMHOOKS_H
 				   Lisp-level event value.
 				   (Only the toolkit version uses these.)  */
   ICONIFY_EVENT,		/* An X client iconified this window.  */
-  DEICONIFY_EVENT,		/* An X client deiconified this window.  */
+  DEICONIFY_EVENT,		/* An X client deiconified this window
+				   or made it visible.  */
   MENU_BAR_ACTIVATE_EVENT,      /* A button press in the menu bar
 				   (toolkit version only).  */
   DRAG_N_DROP_EVENT,		/* A drag-n-drop event is generated when
diff --git a/src/xterm.c b/src/xterm.c
index 6c6a62adb2..2c64411518 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -8166,22 +8166,19 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       f = x_top_window_to_frame (dpyinfo, event->xproperty.window);
       if (f && event->xproperty.atom == dpyinfo->Xatom_net_wm_state)
 	{
+	  bool was_iconified = FRAME_ICONIFIED_P (f);
           bool not_hidden = x_handle_net_wm_state (f, &event->xproperty);

-	  if (not_hidden && FRAME_ICONIFIED_P (f))
+	  if (not_hidden)
 	    {
 	      if (CONSP (frame_size_history))
 		frame_size_history_plain
-		  (f, build_string ("PropertyNotify, not hidden & iconified"));
+		  (f, build_string ("PropertyNotify, not hidden"));

-	      /* Gnome shell does not iconify us when C-z is pressed.
-		 It hides the frame.  So if our state says we aren't
-		 hidden anymore, treat it as deiconified.  */
+	      SET_FRAME_GARBAGED (f);
 	      SET_FRAME_VISIBLE (f, 1);
-	      SET_FRAME_ICONIFIED (f, false);
-
 	      f->output_data.x->has_been_visible = true;
-	      inev.ie.kind = DEICONIFY_EVENT;
+
 #if defined USE_GTK && defined HAVE_GTK3
 	      /* If GTK3 wants to impose some old size here (Bug#24526),
 		 tell it that the current size is what we want.  */
@@ -8192,18 +8189,25 @@ handle_one_xevent (struct x_display_info *dpyinfo,
 		  f->was_invisible = false;
 		}
 #endif
+
+	      SET_FRAME_ICONIFIED (f, false);
+	      inev.ie.kind = DEICONIFY_EVENT;
 	      XSETFRAME (inev.ie.frame_or_window, f);
 	    }
-	  else if (!not_hidden && !FRAME_ICONIFIED_P (f))
+	  else
 	    {
 	      if (CONSP (frame_size_history))
 		frame_size_history_plain
-		  (f, build_string ("PropertyNotify, hidden & not iconified"));
+		  (f, build_string ("PropertyNotify, hidden"));

 	      SET_FRAME_VISIBLE (f, 0);
-	      SET_FRAME_ICONIFIED (f, true);
-	      inev.ie.kind = ICONIFY_EVENT;
-	      XSETFRAME (inev.ie.frame_or_window, f);
+
+	      if (!was_iconified)
+		{
+		  SET_FRAME_ICONIFIED (f, true);
+		  inev.ie.kind = ICONIFY_EVENT;
+		  XSETFRAME (inev.ie.frame_or_window, f);
+		}
 	    }
 	}

@@ -8402,7 +8406,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       f = x_top_window_to_frame (dpyinfo, event->xmap.window);
       if (f)
         {
-	  bool iconified = FRAME_ICONIFIED_P (f);
+	  bool was_iconified = FRAME_ICONIFIED_P (f);
 	  int value;
 	  bool sticky;
           bool not_hidden = x_get_current_wm_state (f, event->xmap.window, &value, &sticky);
@@ -8410,7 +8414,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
 	  if (CONSP (frame_size_history))
 	    frame_size_history_extra
 	      (f,
-	       iconified
+	       was_iconified
 	       ? (not_hidden
 		  ? build_string ("MapNotify, not hidden & iconified")
 		  : build_string ("MapNotify, hidden & iconified"))
@@ -8434,7 +8438,7 @@ handle_one_xevent (struct x_display_info *dpyinfo,
 #endif /* Not USE_GTK */
 	    }

-	  if (!iconified)
+	  if (!was_iconified)
 	    {
 	      /* The `z-group' is reset every time a frame becomes
 		 invisible.  Handle this here.  */
@@ -8459,13 +8463,10 @@ handle_one_xevent (struct x_display_info *dpyinfo,
 		}
 #endif
 	      f->output_data.x->has_been_visible = true;
-	    }

-          if (not_hidden && iconified)
-            {
-              inev.ie.kind = DEICONIFY_EVENT;
-              XSETFRAME (inev.ie.frame_or_window, f);
-            }
+	      inev.ie.kind = DEICONIFY_EVENT;
+	      XSETFRAME (inev.ie.frame_or_window, f);
+	    }
         }
       goto OTHER;

@@ -9354,7 +9355,25 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       f = x_top_window_to_frame (dpyinfo, event->xvisibility.window);
       if (f && (event->xvisibility.state == VisibilityUnobscured
 		|| event->xvisibility.state == VisibilityPartiallyObscured))
-	SET_FRAME_VISIBLE (f, 1);
+	{
+#if defined USE_GTK && defined HAVE_GTK3
+	  /* If GTK3 wants to impose some old size here (Bug#24526),
+	     tell it that the current size is what we want.  */
+	  if (f->was_invisible)
+	    {
+	      xg_frame_set_char_size
+		(f, FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f));
+	      f->was_invisible = false;
+	    }
+#endif
+	  f->output_data.x->has_been_visible = true;
+	  SET_FRAME_GARBAGED (f);
+	  SET_FRAME_VISIBLE (f, 1);
+
+	  SET_FRAME_ICONIFIED (f, false);
+	  inev.ie.kind = DEICONIFY_EVENT;
+	  XSETFRAME (inev.ie.frame_or_window, f);
+	}

       goto OTHER;

bug#49959: 28.0.50; Emacs got quasi freeze

[Masaru Nomiya]

Hello,

In the Message; 

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

[RM] == martin rudalics <rudalics@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 --

bug#49959: 28.0.50; Emacs got quasi freeze

[martin rudalics]

 > 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

bug#49959: 28.0.50; Emacs got quasi freeze

[Masaru Nomiya]

Hello,

In the Message; 

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

[RM] == martin rudalics <rudalics@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'

bug#49959: 28.0.50; Emacs got quasi freeze

[martin rudalics]

 > 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

bug#49959: 28.0.50; Emacs got quasi freeze

[Masaru Nomiya]

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@gmx.at>
  Date & Time: Thu, 26 Aug 2021 09:52:54 +0200

[RM] == martin rudalics <rudalics@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."

bug#49959: 28.0.50; Emacs got quasi freeze

[martin rudalics]

 > 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

bug#49959: Diff file (Was: Re: bug#49959: 28.0.50; Emacs got quasi freeze)

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

 > 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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: FocusIn.diff --]
[-- Type: text/x-patch; name="FocusIn.diff", Size: 4194 bytes --]

diff --git a/src/w32term.c b/src/w32term.c
index 8eb90669d5..9663628045 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -6889,11 +6889,6 @@ w32_make_frame_invisible (struct frame *f)

   my_show_window (f, FRAME_W32_WINDOW (f), SW_HIDE);

-  /* We can't distinguish this from iconification
-     just by the event that we get from the server.
-     So we can't win using the usual strategy of letting
-     FRAME_SAMPLE_VISIBILITY set this.  So do it by hand,
-     and synchronize with the server to make sure we agree.  */
   SET_FRAME_VISIBLE (f, 0);
   SET_FRAME_ICONIFIED (f, false);

diff --git a/src/xdisp.c b/src/xdisp.c
index 049d5ed7b5..b6baf4fd27 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -15429,9 +15429,6 @@ redisplay_internal (void)
       FRAME_TTY (sf)->previous_frame = sf;
     }

-  /* Set the visible flags for all frames.  Do this before checking for
-     resized or garbaged frames; they want to know if their frames are
-     visible.  See the comment in frame.h for FRAME_SAMPLE_VISIBILITY.  */
   number_of_visible_frames = 0;

   FOR_EACH_FRAME (tail, frame)
diff --git a/src/xterm.c b/src/xterm.c
index 6c6a62adb2..d5e40ffcc8 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -8243,12 +8243,32 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       f = x_window_to_frame (dpyinfo, event->xexpose.window);
       if (f)
         {
+	  if (CONSP (frame_size_history))
+	    {
+	      if (FRAME_VISIBLE_P (f))
+		frame_size_history_plain
+		  (f, build_string ("Expose, visible"));
+	      else
+		frame_size_history_plain
+		  (f, build_string ("Expose, not visible"));
+	    }
+
           if (!FRAME_VISIBLE_P (f))
             {
               block_input ();
 	      /* The following two are commented out to avoid that a
 		 plain invisible frame gets reported as iconified.  That
-		 problem occurred first for Emacs 26 and is described in
+		 problem occurred first for Emacs 26 with GTK3 and is
+		 the result of the following actions:
+
+		 (1) x_make_frame_invisible sets f->visible to 0.
+
+		 (2) We get an (unexpected) Expose event for f and here
+		     set f->visible to 1.
+
+		 (3) The subsequent UnmapNotify event finds f->visible
+		     is 1 and sets f->iconified true.
+
 		 https://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00133.html.  */
 /** 	      SET_FRAME_VISIBLE (f, 1); **/
 /** 	      SET_FRAME_ICONIFIED (f, false); **/
@@ -8839,26 +8859,24 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       goto OTHER;

     case FocusIn:
-#ifndef USE_GTK
       /* Some WMs (e.g. Mutter in Gnome Shell), don't unmap
          minimized/iconified windows; thus, for those WMs we won't get
          a MapNotify when unminimizing/deconifying.  Check here if we
-         are deiconizing a window (Bug42655).
-
-	 But don't do that on GTK since it may cause a plain invisible
-	 frame get reported as iconified, compare
-	 https://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00133.html.
-	 That is fixed above but bites us here again.  */
+         are deiconifying a window (Bug42655).  */
       f = any;
+      /* Should we handle invisible frames here too?  */
       if (f && FRAME_ICONIFIED_P (f))
 	{
+	  if (CONSP (frame_size_history))
+	    frame_size_history_plain
+	      (f, build_string ("FocusIn, was iconified"));
+
           SET_FRAME_VISIBLE (f, 1);
           SET_FRAME_ICONIFIED (f, false);
           f->output_data.x->has_been_visible = true;
           inev.ie.kind = DEICONIFY_EVENT;
           XSETFRAME (inev.ie.frame_or_window, f);
         }
-#endif /* USE_GTK */

       x_detect_focus_change (dpyinfo, any, event, &inev.ie);
       goto OTHER;
@@ -11936,11 +11954,6 @@ x_make_frame_invisible (struct frame *f)

   x_sync (f);

-  /* We can't distinguish this from iconification
-     just by the event that we get from the server.
-     So we can't win using the usual strategy of letting
-     FRAME_SAMPLE_VISIBILITY set this.  So do it by hand,
-     and synchronize with the server to make sure we agree.  */
   SET_FRAME_VISIBLE (f, 0);
   SET_FRAME_ICONIFIED (f, false);

bug#49959: Diff file (Was: Re: bug#49959: 28.0.50; Emacs got quasi freeze)

[Masaru Nomiya]

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@gmx.at>
  Date & Time: Tue, 31 Aug 2021 18:51:35 +0200

[MR] == martin rudalics <rudalics@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."

bug#49959: Diff file (Was: Re: bug#49959: 28.0.50; Emacs got quasi freeze)

[martin rudalics]

 > 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

bug#49959: Diff file (Was: Re: bug#49959: 28.0.50; Emacs got quasi freeze)

[Masaru Nomiya]

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@gmx.at>
  Date & Time: Wed, 1 Sep 2021 11:17:27 +0200

[MR] == martin rudalics <rudalics@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 --

bug#49959: 28.0.50; Emacs got quasi freeze

[Lars Ingebrigtsen]

Masaru Nomiya <nomiya@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?

bug#49959: 28.0.50; Emacs got quasi freeze

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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#49959: 28.0.50; Emacs got quasi freeze

[野宮 賢 / NOMIYA Masaru]

Hello,

In the Message; 

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

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

LMI>  Lars Ingebrigtsen <larsi@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@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 --