From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#49959: Diff file (Was: Re: bug#49959: 28.0.50; Emacs got quasi freeze) Date: Tue, 31 Aug 2021 18:51:35 +0200 Message-ID: <6e2372de-749c-889d-98a5-45da734d3d1c@gmx.at> References: <87r1f3vv5r.wl-m.nomiya@gmail.com> <8735r3idtj.wl-nomiya@galaxy.dti.ne.jp> <871r6ni8z5.wl-nomiya@galaxy.dti.ne.jp> <824dbfdc-e25a-5884-69a0-e5d4e9bc9d48@gmx.at> <1df6be5b-7041-d70f-1ae7-8e792b8147b5@gmx.at> <87ilzxdqhi.wl-nomiya@galaxy.dti.ne.jp> <87o89nmyfr.wl-nomiya@galaxy.dti.ne.jp> <87mtp78pzk.wl-nomiya@galaxy.dti.ne.jp> <35b2918d-5755-01e0-ecc9-ec543ee83299@gmx.at> <87mtp7f2bm.wl-nomiya@galaxy.dti.ne.jp> <3876ce8f-bbdb-ccbb-815b-c61e4133f1a8@gmx.at> <87czq1vldp.wl-nomiya@galaxy.dti.ne.jp> <87fsuxhx2e.wl-nomiya@galaxy.dti.ne.jp> <877dg580px.wl-nomiya@galaxy.dti.ne.jp> <1fc12f13-1666-d775-f695-f353fd2f8738@gmx.at> <875yvo8ywt.wl-nomiya@galaxy.dti.ne.jp> <89382a57-874e-81ed-d71f-8301db63ba48@gmx.at> <87h7f5oq0p.wl-m.nomiya@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------607630CE65F93A7CAA867387" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34223"; mail-complaints-to="usenet@ciao.gmane.io" To: m.nomiya@gmail.com, 49959@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 31 18:56:13 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mL73U-0008hv-Mx for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 31 Aug 2021 18:56:12 +0200 Original-Received: from localhost ([::1]:35562 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mL73T-0007Co-JS for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 31 Aug 2021 12:56:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48406) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mL6zS-0001fJ-Ox for bug-gnu-emacs@gnu.org; Tue, 31 Aug 2021 12:52:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52003) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mL6zS-0006cR-G2 for bug-gnu-emacs@gnu.org; Tue, 31 Aug 2021 12:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mL6zS-0007qO-Cd for bug-gnu-emacs@gnu.org; Tue, 31 Aug 2021 12:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 31 Aug 2021 16:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49959 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 49959-submit@debbugs.gnu.org id=B49959.163042870730092 (code B ref 49959); Tue, 31 Aug 2021 16:52:02 +0000 Original-Received: (at 49959) by debbugs.gnu.org; 31 Aug 2021 16:51:47 +0000 Original-Received: from localhost ([127.0.0.1]:35316 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mL6zD-0007pF-3U for submit@debbugs.gnu.org; Tue, 31 Aug 2021 12:51:47 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:45217) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mL6z9-0007of-T7 for 49959@debbugs.gnu.org; Tue, 31 Aug 2021 12:51:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1630428697; bh=kksuGA0W7fpRlVAky/f29zle19skAkib0tMRNSTzduc=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=PYeBl/8eW0kR1+eTSOGgb8eUDgqTd/8JhGhyESQKWy+hIdbMmzfWHyElkiHm5NzNG Rdyqe+pz6t1l/0ZIn0DotHQVNVX8MH5ZHb6qB0BvKCPY9syrMADBxEtzMgm9g/9Be8 zywI+1aX80Q4IbxhFmyU4cu/AU3lLBcrZxQKHjqc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.102] ([213.142.97.37]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MCKFk-1mBnKM3XRi-009Lta; Tue, 31 Aug 2021 18:51:36 +0200 In-Reply-To: <87h7f5oq0p.wl-m.nomiya@gmail.com> Content-Language: en-US X-Provags-ID: V03:K1:5jG7FBJxosbup+6JUuMIcDjHphhZRBTOfIya+9+0o/5PAoOBtoj UWrUbEh8oV3TLJ/3vk4UzyBxW8In0zDZzPxWO8xW3VOlZu6oyvOenCntbgg5tBRU508By/F dt4prQB3/+1+SWX5D9Tfqb5+FGUfAYFt/fmdKjz/AR2QPXnLWeDlxgafZPaH1d7g7XqIQiq lXYV3774cINYIQIlSUH5g== X-UI-Out-Filterresults: notjunk:1;V03:K0:rfPDFwffqG4=:b9dO4JE7B68Xb0eEDf9Xo2 5VZYnTYVs4h9bw1P/O67+Va4RagszI8/shfbIGEnJhTB/wo2vJn7QBbRLWIb2D8PMF4TKKQ7+ VqkPtJ85BTGHKt9Qdv/exEFgcUMg2qw5CsZnLo6vtIDYdcpLl1B968elbOmui+BAj0D5kmd+P 2B+UZbReWV0lKiMYQDzypQttDAglHPY1XJnUHOpt/SI0tSkdRDoo2QBR/oWhHmJDZhaMI0CZf gBpXYZDu5vPjATKfH9MwjAXJICg1ZlYF17LrBy/vH4otleLSzJJnyAcUu+S54UXR0ygDX3FpI yICtnsoYDun+0AtMxJ2URdvjXvAR53hmUQH7/GMVlD5n7Un7UPQjGcOeQ8YOZk56dQDAmyHSw DRn/lvOBegkh4L3tLgXaljlWAWLeD44rS1ok59uFu9OF4TfDGdxfc2DliNabbFcP6EWTaQWDr IsaV31LEuiD1hzGMCN0mJTtxpYNXnvk8rW2OFVVIN/BkUWe8yIGXr+pXTTGYtZgBM4layEE0B lFKjOl2NAqf7TKb1m/M2z7p4iqGKbXIU6ZxmQujnQXHDwVKhvzAohHOeG9wZZ8t/udv2Swirx 17qtVzRg8s5eX6TAT0R1q1eULMM00VNrsq1riHdp47GzgZsGUzFS/HPNOIEhbSO95PMDrI8Wa ujFYeETI/wUtM7ue9YCj+yzgt7SuuVaYWXqSDtH12+zQ2NeAIknZs9DdBQIo54MHIOlSbuttM U5DK5dUFCUFhSfXys0MreiP68qnUgE4tUN5tznxDeJNxBgHquA0Nq57JqAiWjgTqr5/lxYvh X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:213112 Archived-At: This is a multi-part message in MIME format. --------------607630CE65F93A7CAA867387 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit > 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 --------------607630CE65F93A7CAA867387 Content-Type: text/x-patch; name="FocusIn.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="FocusIn.diff" diff --git a/src/w32term.c b/src/w32term.c index 8eb90669d5..9663628045 100644 =2D-- 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 =2D-- a/src/xdisp.c +++ b/src/xdisp.c @@ -15429,9 +15429,6 @@ redisplay_internal (void) FRAME_TTY (sf)->previous_frame =3D 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 =3D 0; FOR_EACH_FRAME (tail, frame) diff --git a/src/xterm.c b/src/xterm.c index 6c6a62adb2..d5e40ffcc8 100644 =2D-- a/src/xterm.c +++ b/src/xterm.c @@ -8243,12 +8243,32 @@ handle_one_xevent (struct x_display_info *dpyinfo, f =3D 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 =3D 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 =3D true; inev.ie.kind =3D 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); --------------607630CE65F93A7CAA867387--