emacs-28 ef0c1d4c2c: Add workaround to handle a problem with Enlightenment WM (Bug#53298)

[Martin Rudalics]

branch: emacs-28
commit ef0c1d4c2c8eefe599f50bc99b3dd088433a2842
Author: Martin Rudalics <rudalics@gmx.at>
Commit: Martin Rudalics <rudalics@gmx.at>

    Add workaround to handle a problem with Enlightenment WM (Bug#53298)
    
    * src/xterm.c (handle_one_xevent): Handle setting of variable
    'x_set_frame_visibility_more_laxly' when receiving an Expose or
    FocusIn event (Bug#53298).
    (Qexpose): Define symbol.
    (x_set_frame_visibility_more_laxly): New Lisp variable.
    * etc/PROBLEMS: Mention frame redraw problem with the
    Enlightenment WM and 'x-set-frame-visibility-more-laxly'
    workaround.
---
 etc/PROBLEMS |  7 ++++++
 src/xterm.c  | 69 ++++++++++++++++++++++++++++++++++++++++++------------------
 2 files changed, 56 insertions(+), 20 deletions(-)

diff --git a/etc/PROBLEMS b/etc/PROBLEMS
index eb685e5bfb..e48ce5a8b0 100644
--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -1269,6 +1269,13 @@ and then Alt-F7).  A bug for it is here:
 https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/231034.
 Note that a permanent fix seems to be to disable "assistive technologies".
 
+*** Enlightenment: Frames not redrawn after switching virtual desktops
+
+With Enlightenment version 0.25, Emacs frames may no be redrawn orderly
+after switching back from another virtual desktop.  Setting the variable
+'x-set-frame-visibility-more-laxly' to one of 'focus-in', 'expose' or
+'t' should fix this.
+
 *** Gnome: Emacs receives input directly from the keyboard, bypassing XIM.
 
 This seems to happen when gnome-settings-daemon version 2.12 or later
diff --git a/src/xterm.c b/src/xterm.c
index b55a54b945..b80d45f855 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -8231,12 +8231,17 @@ handle_one_xevent (struct x_display_info *dpyinfo,
           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
-                
https://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00133.html.  */
-/**          SET_FRAME_VISIBLE (f, 1); **/
-/**          SET_FRAME_ICONIFIED (f, false); **/
+             /* By default, do not set the frame's visibility here, see
+                
https://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00133.html.
+                The default behavior can be overridden by setting
+                'x-set-frame-visibility-more-laxly' (Bug#49955,
+                Bug#53298).  */
+             if (EQ (x_set_frame_visibility_more_laxly, Qexpose)
+                 || EQ (x_set_frame_visibility_more_laxly, Qt))
+               {
+                 SET_FRAME_VISIBLE (f, 1);
+                 SET_FRAME_ICONIFIED (f, false);
+               }
 
              if (FRAME_X_DOUBLE_BUFFERED_P (f))
                 font_drop_xrender_surfaces (f);
@@ -8824,26 +8829,33 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       goto OTHER;
 
     case FocusIn:
-#ifndef USE_GTK
+#ifdef 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
+         a MapNotify when unminimizing/deiconifying.  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
+        But don't do that by default 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.  */
-      f = any;
-      if (f && FRAME_ICONIFIED_P (f))
-       {
-          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);
-        }
+        That is fixed above but bites us here again.
+
+        The option x_set_frame_visibility_more_laxly allows to override
+        the default behavior (Bug#49955, Bug#53298).  */
+      if (EQ (x_set_frame_visibility_more_laxly, Qfocus_in)
+         || EQ (x_set_frame_visibility_more_laxly, Qt))
 #endif /* USE_GTK */
+       {
+         f = any;
+         if (f && FRAME_ICONIFIED_P (f))
+           {
+             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);
+           }
+       }
 
       x_detect_focus_change (dpyinfo, any, event, &inev.ie);
       goto OTHER;
@@ -13779,4 +13791,21 @@ gtk_window_move to set or store frame positions and 
disables some time
 consuming frame position adjustments.  In newer versions of GTK, Emacs
 always uses gtk_window_move and ignores the value of this variable.  */);
   x_gtk_use_window_move = true;
+
+  DEFSYM (Qexpose, "expose");
+
+  DEFVAR_LISP ("x-set-frame-visibility-more-laxly",
+              x_set_frame_visibility_more_laxly,
+    doc: /* Non-nil means set frame visibility more laxly.
+If this is nil, Emacs is more strict when marking a frame as visible.
+Since this may cause problems on some window managers, this variable can
+be also set as follows: The value `focus-in' means to mark a frame as
+visible also when a FocusIn event is received for it on GTK builds.  The
+value `expose' means to mark a frame as visible also when an Expose
+event is received for it on any X build.  The value `t' means to mark a
+frame as visible in either of these two cases.
+
+Note that any non-nil setting may cause invisible frames get erroneously
+reported as iconified.  */);
+  x_set_frame_visibility_more_laxly = Qnil;
 }