GNU bug report logs -
#42655
27.1; iconify-frame on a Lucid build may stuck the frame
Previous Next
Reported by: Tino Calancha <tino.calancha <at> gmail.com>
Date: Sat, 1 Aug 2020 18:47:01 UTC
Severity: wishlist
Found in version 27.1
Done: Tino Calancha <tino.calancha <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 42655 in the body.
You can then email your comments to 42655 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
monnier <at> iro.umontreal.ca, eggert <at> cs.ucla.edu, uyennhi.qm <at> gmail.com, bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Sat, 01 Aug 2020 18:47:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Tino Calancha <tino.calancha <at> gmail.com>:
New bug report received and forwarded. Copy sent to
monnier <at> iro.umontreal.ca, eggert <at> cs.ucla.edu, uyennhi.qm <at> gmail.com, bug-gnu-emacs <at> gnu.org.
(Sat, 01 Aug 2020 18:47:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
X-Debbugs-Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, Paul Eggert <eggert <at> cs.ucla.edu>, <uyennhi.qm <at> gmail.com>
Severity: wishlist
* To reproduce
-------------------------------------------------------------------------------
In a GUI session, with Emacs built with Lucid toolkit in a Linux machine,
do:
emacs -Q
C-z
;; select again the window displaying the Emacs GUI
-------------------------------------------------------------------------------
- You cannot insert characters in the *scratch* buffer.
- Normal movement, for intance, `C-n' or `C-f' doesn't work.
trick: `M-x' recovers the frame.
Unfortunately, when I start Emacs without the `-Q' flag, then this trick
doesn't work for me: the frame keeps unresponsive forever, and I have 2 choices:
1) Restart Emacs session (unaceptable for users).
2) Get 'blindly' (ie, without echo area feedback) a new frame:
C-x 5 b foo RET
* Expected behavior:
After `C-z' and select again the Emacs GUI you have a fully responsive
frame displaying the *scratch* buffer: you can insert characters and/or
move the cursor anywhere.
* Workaround:
Install gtk3-devel and build Emacs with GTK3 toolkit
In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2020-08-01 built on calancha-pc.dy.bbexcite.jp
Repository revision: f54ddb0198640e38c1d34bf6031ff5117c117c85
Repository branch: emacs-27
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux 10 (buster)
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit [2 times]
funcall-interactively: End of buffer
scroll-up-command: End of buffer
Configured using:
'configure --with-x-toolkit=lucid'
Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS
LIBSYSTEMD PDUMPER LCMS2 GMP
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 16 44708 6402)
(symbols 48 5984 1)
(strings 32 16489 1646)
(string-bytes 1 525028)
(vectors 16 9267)
(vector-slots 8 124678 11056)
(floats 8 22 43)
(intervals 56 212 0)
(buffers 1000 11))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Sat, 01 Aug 2020 18:54:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 42655 <at> debbugs.gnu.org (full text, mbox):
> From: Tino Calancha <tino.calancha <at> gmail.com>
> Date: Sat, 01 Aug 2020 20:46:03 +0200
> Cc: paul eggert <eggert <at> cs.ucla.edu>, stefan monnier <monnier <at> iro.umontreal.ca>,
> uyennhi.qm <at> gmail.com
>
> In a GUI session, with Emacs built with Lucid toolkit in a Linux machine,
> do:
> emacs -Q
> C-z
> ;; select again the window displaying the Emacs GUI
> -------------------------------------------------------------------------------
>
> - You cannot insert characters in the *scratch* buffer.
> - Normal movement, for intance, `C-n' or `C-f' doesn't work.
If you now attach a debugger to Emacs, what does the backtrace show?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Sun, 02 Aug 2020 13:08:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 42655 <at> debbugs.gnu.org (full text, mbox):
Tino Calancha <tino.calancha <at> gmail.com> writes:
> -------------------------------------------------------------------------------
> In a GUI session, with Emacs built with Lucid toolkit in a Linux machine,
> do:
> emacs -Q
> C-z
> ;; select again the window displaying the Emacs GUI
> -------------------------------------------------------------------------------
>
> - You cannot insert characters in the *scratch* buffer.
> - Normal movement, for intance, `C-n' or `C-f' doesn't work.
It is a regression from Emacs 26.? with the following commit:
commit dee8674414fae2323fd9cbf05aa762e72fa575e5
Author: Stefan Monnier <monnier <at> iro.umontreal.ca>
Date: Thu Feb 23 21:17:04 2017 -0500
Minor redisplay optimisations
* src/frame.c (Ficonify_frame): No need to redisplay everything.
The following patch fixed it:
--8<-----------------------------cut here---------------start------------->8---
commit 96e56d237d27d0873914319812a576969f60486f
Author: Tino Calancha <ccalancha <at> suse.com>
Date: Sun Aug 2 14:45:56 2020 +0200
Notify when a frame is iconified in Lucid builds
If Emacs is built without x toolkit or built with Lucid,
then we have to notify when a frame is iconified (Bug#42655).
- src/frame (iconify-frame):
Set windows_or_buffers_changed to a non-zero value.
diff --git a/src/frame.c b/src/frame.c
index 4dd8bb1804..640aa5c4e3 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -2738,6 +2738,11 @@ DEFUN ("iconify-frame", Ficonify_frame, Siconify_frame,
if (FRAME_WINDOW_P (f) && FRAME_TERMINAL (f)->iconify_frame_hook)
FRAME_TERMINAL (f)->iconify_frame_hook (f);
+#if (!defined USE_X_TOOLKIT || defined USE_LUCID) /* (Bug#42655) */
+ /* Make menu bar update for the Buffers and Frames menus. */
+ windows_or_buffers_changed = 17;
+#endif
+
return Qnil;
}
--8<-----------------------------cut here---------------end--------------->8---
In GNU Emacs 27.1 (build 17, x86_64-pc-linux-gnu, X toolkit, Xaw scroll bars)
of 2020-08-02 built on localhost.example.com
Repository revision: f54ddb0198640e38c1d34bf6031ff5117c117c85
Repository branch: emacs-27
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: openSUSE Tumbleweed
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Sun, 02 Aug 2020 14:35:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 42655 <at> debbugs.gnu.org (full text, mbox):
> From: Tino Calancha <tino.calancha <at> gmail.com>
> Date: Sun, 02 Aug 2020 15:07:32 +0200
> Cc: paul eggert <eggert <at> cs.ucla.edu>, stefan monnier <monnier <at> iro.umontreal.ca>,
> uyennhi.qm <at> gmail.com
>
> Tino Calancha <tino.calancha <at> gmail.com> writes:
>
> > emacs -Q
> > C-z
> > ;; select again the window displaying the Emacs GUI
> > -------------------------------------------------------------------------------
> >
> > - You cannot insert characters in the *scratch* buffer.
> > - Normal movement, for intance, `C-n' or `C-f' doesn't work.
>
> It is a regression from Emacs 26.? with the following commit:
>
> commit dee8674414fae2323fd9cbf05aa762e72fa575e5
> Author: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Thu Feb 23 21:17:04 2017 -0500
>
> Minor redisplay optimisations
>
> * src/frame.c (Ficonify_frame): No need to redisplay everything.
>
> The following patch fixed it:
>
> --8<-----------------------------cut here---------------start------------->8---
> commit 96e56d237d27d0873914319812a576969f60486f
> Author: Tino Calancha <ccalancha <at> suse.com>
> Date: Sun Aug 2 14:45:56 2020 +0200
>
> Notify when a frame is iconified in Lucid builds
>
> If Emacs is built without x toolkit or built with Lucid,
> then we have to notify when a frame is iconified (Bug#42655).
> - src/frame (iconify-frame):
> Set windows_or_buffers_changed to a non-zero value.
>
> diff --git a/src/frame.c b/src/frame.c
> index 4dd8bb1804..640aa5c4e3 100644
> --- a/src/frame.c
> +++ b/src/frame.c
> @@ -2738,6 +2738,11 @@ DEFUN ("iconify-frame", Ficonify_frame, Siconify_frame,
> if (FRAME_WINDOW_P (f) && FRAME_TERMINAL (f)->iconify_frame_hook)
> FRAME_TERMINAL (f)->iconify_frame_hook (f);
>
> +#if (!defined USE_X_TOOLKIT || defined USE_LUCID) /* (Bug#42655) */
> + /* Make menu bar update for the Buffers and Frames menus. */
> + windows_or_buffers_changed = 17;
> +#endif
Thanks, but I'm afraid this is not necessarily TRT. You simply revert
part of Stefan's change for some configurations, but I don't
understand why not setting windows_or_buffers_changed affects Lucid,
but not GTK. Did you succeed in understanding the reason?
And btw, why do you also add this for non-toolkit builds: did you see
the same problem in that configuration?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Mon, 03 Aug 2020 19:48:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 42655 <at> debbugs.gnu.org (full text, mbox):
> Thanks, but I'm afraid this is not necessarily TRT. You simply revert
> part of Stefan's change for some configurations, but I don't
> understand why not setting windows_or_buffers_changed affects Lucid,
> but not GTK. Did you succeed in understanding the reason?
I don't know the reason. For some reason, Stefan optimisation
affects Lucid; probably he did not test his patch for that
configuration.
If someone wants to dig deeper, it is very welcome; if nobody can,
please, consider applying this simple patch.
I have been suffering this bug for months; until I realized I was able to
workaround getting a new frame, I was just closing the Emacs session
with dozens of visited buffers :-|
> And btw, why do you also add this for non-toolkit builds: did you see
> the same problem in that configuration?
I have reproduced the bug with both flags
--with-x-toolkit=no
and
--with-x-toolkit=lucid
I am just trying to cover in the patch all scenario where I have
reproduced the bug; I can not test other configurations.
How about in Windows? Have you seen this bug?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Mon, 03 Aug 2020 21:30:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 42655 <at> debbugs.gnu.org (full text, mbox):
FWIW, it would be worthwhile to investigate the origin/cause of the
problem, but as a stopgap his patch looks fine to me (I'd add a FIXME
in the comment, indicating that this is just a workaround rather than
a real fix).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Tue, 04 Aug 2020 02:22:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 42655 <at> debbugs.gnu.org (full text, mbox):
> From: Tino Calancha <tino.calancha <at> gmail.com>
> Date: Mon, 3 Aug 2020 21:46:49 +0200 (CEST)
> cc: Tino Calancha <tino.calancha <at> gmail.com>, 42655 <at> debbugs.gnu.org,
> eggert <at> cs.ucla.edu, monnier <at> iro.umontreal.ca, uyennhi.qm <at> gmail.com
>
> How about in Windows? Have you seen this bug?
No, nothing like that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Tue, 04 Aug 2020 04:01:02 GMT)
Full text and
rfc822 format available.
Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
In any case, I asked for a C-level backtrace when I responded to your original report. Can you please attach a debugger to Emacs after selecting the previously iconified frame, and show such a backtrace? Please do that with an unpatched Emacs and in "emacs -Q".
Thanks.
On August 4, 2020 5:21:21 AM GMT+03:00, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Tino Calancha <tino.calancha <at> gmail.com>
>> Date: Mon, 3 Aug 2020 21:46:49 +0200 (CEST)
>> cc: Tino Calancha <tino.calancha <at> gmail.com>, 42655 <at> debbugs.gnu.org,
>> eggert <at> cs.ucla.edu, monnier <at> iro.umontreal.ca,
>uyennhi.qm <at> gmail.com
>>
>> How about in Windows? Have you seen this bug?
>
>No, nothing like that.
--
נשלח ממכשיר האנדרואיד שלי בעזרת אפליקציית הדואר K-9. סלח לי על הקצרנות.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Tue, 04 Aug 2020 04:01:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Tue, 04 Aug 2020 14:21:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 42655 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 04 Aug 2020 06:59:59 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: eggert <at> cs.ucla.edu, monnier <at> iro.umontreal.ca, uyennhi.qm <at> gmail.com
>
> In any case, I asked for a C-level backtrace when I responded to your original report. Can you please attach
> a debugger to Emacs after selecting the previously iconified frame, and show such a backtrace? Please do
> that with an unpatched Emacs and in "emacs -Q".
Also, I don't understand what you mean in your original report by
"unresponsive frame" and "cannot insert characters". Do you mean that
Emacs is "stuck" and doesn't respond, or do you mean that the results
of whatever you do are not displayed? And what _do_ you see displayed
when you "select the window displaying the Emacs GUI" after C-z?
If the problem is with display, then does it help to type (blindly)
"M-x redraw-display RET"?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Tue, 04 Aug 2020 15:16:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 42655 <at> debbugs.gnu.org (full text, mbox):
I was able to reproduce this with Lucid. I will try to read about
attaching debugger and post the results here.
On Tue, 4 Aug 2020 at 19:59, Eli Zaretskii <eliz <at> gnu.org> wrote:
> Also, I don't understand what you mean in your original report by
> "unresponsive frame" and "cannot insert characters". Do you mean that
> Emacs is "stuck" and doesn't respond, or do you mean that the results
> of whatever you do are not displayed?
The latter. The frame gets frozen, whatever we do is not displayed. The
menu bar is functional though.
> And what _do_ you see displayed when you "select the window displaying
> the Emacs GUI" after C-z?
It's just shown as frozen in a state before we press C-z. I ran M-x zone
and then pressed C-z, the frame was frozen with 'Zoning...sorry' in the
minibuffer.
> If the problem is with display, then does it help to type (blindly)
> "M-x redraw-display RET"?
No it doesn't. The only thing worked was to create a new frame.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Tue, 04 Aug 2020 16:42:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 42655 <at> debbugs.gnu.org (full text, mbox):
> From: Bhavin Gandhi <bhavin7392 <at> gmail.com>
> Date: Tue, 4 Aug 2020 20:44:35 +0530
> Cc: tino.calancha <at> gmail.com, 42655 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu,
> monnier <at> iro.umontreal.ca, uyennhi.qm <at> gmail.com
>
> > If the problem is with display, then does it help to type (blindly)
> > "M-x redraw-display RET"?
>
> No it doesn't.
Fascinating.
> The only thing worked was to create a new frame.
And when you do create a new frame, do you see the redraw-display
command in the command history? Also, what does "C-h l" show in that
other frame?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Tue, 04 Aug 2020 18:54:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 42655 <at> debbugs.gnu.org (full text, mbox):
On Tue, 4 Aug 2020 at 22:11, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> And when you do create a new frame, do you see the redraw-display
> command in the command history? Also, what does "C-h l" show in that
> other frame?
Yes, I can see the redraw-display command in command-history. This is
what "C-h l" shows.
--8<---------------cut here---------------start------------->8---
C-z ;; suspend-frame
M-x ;; execute-extended-command
r ;; self-insert-command
e ;; self-insert-command
d ;; self-insert-command
r ;; self-insert-command
<return> ;; minibuffer-complete-and-exit
C-x 5 2 ;; make-frame-command
;; handle-switch-frame
C-h l ;; view-lossage
--8<---------------cut here---------------end--------------->8---
> If you now attach a debugger to Emacs, what does the backtrace show?
Is running "gdb -i=mi -p PID" enough to generate this backtrace?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Tue, 04 Aug 2020 19:09:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 42655 <at> debbugs.gnu.org (full text, mbox):
> From: Bhavin Gandhi <bhavin7392 <at> gmail.com>
> Date: Wed, 5 Aug 2020 00:23:09 +0530
> Cc: tino.calancha <at> gmail.com, 42655 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu,
> monnier <at> iro.umontreal.ca, uyennhi.qm <at> gmail.com
>
> On Tue, 4 Aug 2020 at 22:11, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > And when you do create a new frame, do you see the redraw-display
> > command in the command history? Also, what does "C-h l" show in that
> > other frame?
>
> Yes, I can see the redraw-display command in command-history. This is
> what "C-h l" shows.
>
> --8<---------------cut here---------------start------------->8---
> C-z ;; suspend-frame
> M-x ;; execute-extended-command
> r ;; self-insert-command
> e ;; self-insert-command
> d ;; self-insert-command
> r ;; self-insert-command
> <return> ;; minibuffer-complete-and-exit
> C-x 5 2 ;; make-frame-command
> ;; handle-switch-frame
> C-h l ;; view-lossage
> --8<---------------cut here---------------end--------------->8---
So Emacs is nor stuck, it just doesn't redraw that frame for some
reason.
> > If you now attach a debugger to Emacs, what does the backtrace show?
>
> Is running "gdb -i=mi -p PID" enough to generate this backtrace?
Yes. Then type "thread apply all bt" once inside GDB. But you only
need the -i=mi part if you invoke GDB from Emacs, via "M-x gdb RET".
If you invoke GDB from the shell prompt, it is better to omit -i=mi.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Wed, 05 Aug 2020 17:24:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 42655 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, 5 Aug 2020 at 00:37, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > > If you now attach a debugger to Emacs, what does the backtrace show?
> >
> > Is running "gdb -i=mi -p PID" enough to generate this backtrace?
>
> Yes. Then type "thread apply all bt" once inside GDB. But you only
> need the -i=mi part if you invoke GDB from Emacs, via "M-x gdb RET".
> If you invoke GDB from the shell prompt, it is better to omit -i=mi.
Thanks for the suggestion, here is the backtrace at the point when Emacs
is stuck. Adding it as an attachment.
[bug-42655-backtrace (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Wed, 05 Aug 2020 18:25:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 42655 <at> debbugs.gnu.org (full text, mbox):
On Tue, 4 Aug 2020, Bhavin Gandhi wrote:
>> If the problem is with display, then does it help to type (blindly)
>> "M-x redraw-display RET"?
>
> No it doesn't. The only thing worked was to create a new frame.
Bhavin, have you started the Emacs session with `Emacs -Q`?
In my case, I got the super-nasty scenario (ie, only works to create a new
frame) when I load my custom libraries.
If I start with `Emacs -Q` it is less severe: te frame wakes up
if I input:
M-x
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Wed, 05 Aug 2020 18:33:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 42655 <at> debbugs.gnu.org (full text, mbox):
On Wed, 5 Aug 2020 at 23:54, Tino Calancha <tino.calancha <at> gmail.com> wrote:
> >> If the problem is with display, then does it help to type (blindly)
> >> "M-x redraw-display RET"?
> >
> > No it doesn't. The only thing worked was to create a new frame.
> Bhavin, have you started the Emacs session with `Emacs -Q`?
No, this was a normal start with `emacs`.
> In my case, I got the super-nasty scenario (ie, only works to create a new
> frame) when I load my custom libraries.
>
> If I start with `Emacs -Q` it is less severe: te frame wakes up
> if I input:
> M-x
I had exactly the same behavior.
> here is the backtrace at the point when Emacs is stuck.
This backtrace was created with `emacs -Q` as Eli suggested initially.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Wed, 05 Aug 2020 18:36:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 42655 <at> debbugs.gnu.org (full text, mbox):
On Thu, 6 Aug 2020, Bhavin Gandhi wrote:
>> Bhavin, have you started the Emacs session with `Emacs -Q`?
>
> No, this was a normal start with `emacs`.
> I had exactly the same behavior.
Thanks for the clarification.
>> here is the backtrace at the point when Emacs is stuck.
> This backtrace was created with `emacs -Q` as Eli suggested initially.
Thank you. I hope Eli can get some hint from it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Wed, 05 Aug 2020 18:45:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 42655 <at> debbugs.gnu.org (full text, mbox):
> From: Bhavin Gandhi <bhavin7392 <at> gmail.com>
> Date: Wed, 5 Aug 2020 22:53:15 +0530
> Cc: tino.calancha <at> gmail.com, 42655 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu,
> monnier <at> iro.umontreal.ca, uyennhi.qm <at> gmail.com
>
> Thanks for the suggestion, here is the backtrace at the point when Emacs
> is stuck. Adding it as an attachment.
Thanks, this backtrace says that Emacs is just waiting for input.
Please try this now, after attaching the debugger:
(gdb) source /path/to/emacs/src/.gdbinit
(gdb) p selected_frame
(gdb) xtype
(replace "/path/to/emacs" with the actual absolute file name of the
Emacs source tree on your system). Then post here the results. And
please keep the GDB session running, don't exit it and don't kill
Emacs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Wed, 05 Aug 2020 18:58:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 42655 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Please try this now, after attaching the debugger:
>
> (gdb) source /path/to/emacs/src/.gdbinit
> (gdb) p selected_frame
> (gdb) xtype
(gdb)
source .gdbinit
&"source .gdbinit\n"
~"SIGINT is used by the debugger.\nAre you sure you want to change it? "
~"(y or n) [answered Y; input not from terminal]\n"
=cmd-param-changed,param="print pretty",value="on"
~"DISPLAY = :0\n"
~"TERM = xterm\n"
~"Breakpoint 1 at 0x59d9ad: file emacs.c, line 378.\n"
=breakpoint-created,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000059d9ad",func="terminate_due_to_signal",file="emacs.c",fullname="/home/calancha/soft/emacs-master/src/emacs.c",line="378",thread-groups=["i1"],times="0",original-location="terminate_due_to_signal"}
~"Breakpoint 2 at 0x56d2e3: file xterm.c, line 10135.\n"
=breakpoint-created,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x000000000056d2e3",func="x_error_quitter",file="xterm.c",fullname="/home/calancha/soft/emacs-master/src/xterm.c",line="10135",thread-groups=["i1"],times="0",original-location="x_error_quitter"}
^done
(gdb)
p selected_frame
&"p selected_frame\n"
~"$1 = XIL(0x14f0835)\n"
^done
(gdb)
xtype
&"xtype\n"
~"Lisp_Vectorlike"
~"\n"
~"PVEC_FRAME"
~"\n"
^done
(gdb)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Thu, 06 Aug 2020 02:30:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 42655 <at> debbugs.gnu.org (full text, mbox):
> From: Tino Calancha <tino.calancha <at> gmail.com>
> Cc: Bhavin Gandhi <bhavin7392 <at> gmail.com>, uyennhi.qm <at> gmail.com,
> 42655 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, monnier <at> iro.umontreal.ca
> Date: Wed, 05 Aug 2020 20:57:18 +0200
>
> (gdb)
> p selected_frame
> &"p selected_frame\n"
> ~"$1 = XIL(0x14f0835)\n"
> ^done
> (gdb)
> xtype
> &"xtype\n"
> ~"Lisp_Vectorlike"
> ~"\n"
> ~"PVEC_FRAME"
> ~"\n"
> ^done
> (gdb)
OK, now the important part:
(gdb) p XFRAME (selected_frame)
(gdb) p *$
The last command should display all the members of 'struct frame' that
correspond to the frame which doesn't redisplay.
Just to be sure: you are typing these commands in a situation where
you did NOT yet create another frame, this is the same frame which was
iconified by C-z, right? I want to be sure we display the problematic
frame, not some other one.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Thu, 06 Aug 2020 05:42:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 42655 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, 6 Aug 2020 at 07:59, Eli Zaretskii <eliz <at> gnu.org> wrote:
> OK, now the important part:
>
> (gdb) p XFRAME (selected_frame)
This gave an error for me, I tried the following commands.
(gdb) p XFRAME (selected_frame)
No symbol "XFRAME" in current context.
(gdb) p xframe (selected_frame)
No symbol "xframe" in current context.
But xframe (selected_frame) worked.
> (gdb) p *$
>
> The last command should display all the members of 'struct frame' that
> correspond to the frame which doesn't redisplay.
(gdb) p selected_frame
$1 = XIL(0x1e81975)
(gdb) xtype
Lisp_Vectorlike
PVEC_FRAME
(gdb) xframe (selected_frame)
$2 = (struct frame *) 0x1e81970
"emacs <at> toolbox"
(gdb) p *$
Attaching the output as a file. This is the only frame in that Emacs
instance and it's frozen. I'm keeping gdb and Emacs running in case if
we need it.
[bug-42655-struct-frame (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Thu, 06 Aug 2020 07:44:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 42655 <at> debbugs.gnu.org (full text, mbox):
On August 6, 2020 8:41:12 AM GMT+03:00, Bhavin Gandhi <bhavin7392 <at> gmail.com> wrote:
>
> (gdb) p selected_frame
> $1 = XIL(0x1e81975)
> (gdb) xtype
> Lisp_Vectorlike
> PVEC_FRAME
> (gdb) xframe (selected_frame)
> $2 = (struct frame *) 0x1e81970
> "emacs <at> toolbox"
> (gdb) p *$
>
>Attaching the output as a file.
Thanks. This clearly shows that Emacs considers the frame as being still iconified.
Please tell what does the following yield:
(gdb) p *$2->output_data.x
This assumes that $2 is as you have show previously, i.e. a pointer to struct frame that corresponds to the selected frame.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Thu, 06 Aug 2020 08:14:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 42655 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Please tell what does the following yield:
>
> (gdb) p *$2->output_data.x
>
> This assumes that $2 is as you have show previously, i.e. a pointer to struct frame that corresponds to the selected frame.
(gdb) xframe (selected_frame)
$3 = (struct frame *) 0x234f888
"emacs <at> localhost.example.com"
(gdb) p *$3->output_data.x
$4 = {
menubar_height = 29,
toolbar_top_height = 0,
toolbar_bottom_height = 0,
toolbar_left_width = 0,
toolbar_right_width = 0,
border_tile = 18874720,
normal_gc = 0x233c280,
reverse_gc = 0x223db40,
cursor_gc = 0x2251400,
window_desc = 18874715,
draw_desc = 18874716,
need_buffer_flip = false,
icon_desc = 0,
parent_desc = 8405122,
widget = 0x241c240,
column_widget = 0x221f610,
edit_widget = 0x2220390,
menubar_widget = 0x22f2b40,
icon_bitmap = 1,
font = 0x23ea680,
baseline_offset = 0,
fontset = 2,
cursor_pixel = 0,
border_pixel = 0,
mouse_pixel = 0,
cursor_foreground_pixel = 16777215,
scroll_bar_foreground_pixel = 18446744073709551615,
scroll_bar_background_pixel = 18446744073709551615,
scroll_bar_top_shadow_pixel = 18446744073709551615,
scroll_bar_bottom_shadow_pixel = 18446744073709551615,
text_cursor = 18874392,
nontext_cursor = 18874396,
modeline_cursor = 18874641,
hand_cursor = 18874645,
hourglass_cursor = 18874637,
horizontal_drag_cursor = 18874649,
vertical_drag_cursor = 18874653,
current_cursor = 18874396,
left_edge_cursor = 18874657,
top_left_corner_cursor = 18874661,
top_edge_cursor = 18874665,
top_right_corner_cursor = 18874669,
right_edge_cursor = 18874673,
bottom_right_corner_cursor = 18874677,
bottom_edge_cursor = 18874681,
bottom_left_corner_cursor = 18874685,
hourglass_window = 0,
wm_hints = {
flags = 1,
input = 1,
initial_state = 0,
icon_pixmap = 18874722,
icon_window = 0,
icon_x = 0,
icon_y = 0,
icon_mask = 18874724,
window_group = 0
},
display_info = 0x222c5c0,
saved_menu_event = 0x248a670,
id = 1,
hourglass_p = false,
explicit_parent = false,
asked_for_visible = true,
has_been_visible = true,
wait_for_wm = true,
xic = 0x24269a0,
xic_style = 1028,
xic_xfs = 0x2423880,
black_relief = {
gc = 0x21e8220,
pixel = 7566195
},
white_relief = {
gc = 0x23e2ca0,
pixel = 15132390
},
relief_background = 12566463,
focus_state = 1,
move_offset_top = 0,
move_offset_left = 0,
cr_context = 0x22734b0,
cr_surface_desired_width = 674,
cr_surface_desired_height = 633
}
(gdb)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Thu, 06 Aug 2020 13:48:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 42655 <at> debbugs.gnu.org (full text, mbox):
> From: Tino Calancha <tino.calancha <at> gmail.com>
> Cc: Bhavin Gandhi <bhavin7392 <at> gmail.com>, 42655 <at> debbugs.gnu.org,
> eggert <at> cs.ucla.edu, uyennhi.qm <at> gmail.com, monnier <at> iro.umontreal.ca
> Date: Thu, 06 Aug 2020 10:13:06 +0200
>
> > (gdb) p *$2->output_data.x
> >
> > This assumes that $2 is as you have show previously, i.e. a pointer to struct frame that corresponds to the selected frame.
>
> (gdb) xframe (selected_frame)
> $3 = (struct frame *) 0x234f888
> "emacs <at> localhost.example.com"
> (gdb) p *$3->output_data.x
> $4 = {
Thanks. Looks like we never get the MapNotify event from X windows?
Can you verify that, either by running the xev utility or by setting a
breakpoint in xterm.c:handle_one_xevent when MapNotify is handled, and
repeating the recipe?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Thu, 06 Aug 2020 13:58:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 42655 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 06 Aug 2020 16:47:00 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 42655 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, uyennhi.qm <at> gmail.com,
> bhavin7392 <at> gmail.com, monnier <at> iro.umontreal.ca
>
> Thanks. Looks like we never get the MapNotify event from X windows?
> Can you verify that, either by running the xev utility or by setting a
> breakpoint in xterm.c:handle_one_xevent when MapNotify is handled, and
> repeating the recipe?
And one more thing: does it help to disable double-buffering?
(NEWS.26 explains how to do that.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Thu, 06 Aug 2020 14:19:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 42655 <at> debbugs.gnu.org (full text, mbox):
On Thu, 6 Aug 2020, Eli Zaretskii wrote:
> And one more thing: does it help to disable double-buffering?
> (NEWS.26 explains how to do that.)
This doesn't help :-(
[ I will investigate the other tips ]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Thu, 06 Aug 2020 14:38:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 42655 <at> debbugs.gnu.org (full text, mbox):
On Thu, 6 Aug 2020, Eli Zaretskii wrote:
> Thanks. Looks like we never get the MapNotify event from X windows?
> Can you verify that, either by running the xev utility or by setting a
> breakpoint in xterm.c:handle_one_xevent when MapNotify is handled, and
> repeating the recipe?
Set breakpoint at
xterm::8348
C-z ; frame is hidden
;; I select again the hidden frame
;; gdb doesn't jump to the breakpoint and the frame is 'cursed'
M-x
;; The frame wakes up and gdb reaches the breakpoint.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Fri, 07 Aug 2020 05:54:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 42655 <at> debbugs.gnu.org (full text, mbox):
> From: Tino Calancha <tino.calancha <at> gmail.com>
> Date: Thu, 6 Aug 2020 16:37:18 +0200 (CEST)
> cc: Tino Calancha <tino.calancha <at> gmail.com>, bhavin7392 <at> gmail.com,
> 42655 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, uyennhi.qm <at> gmail.com,
> monnier <at> iro.umontreal.ca
>
> > Thanks. Looks like we never get the MapNotify event from X windows?
> > Can you verify that, either by running the xev utility or by setting a
> > breakpoint in xterm.c:handle_one_xevent when MapNotify is handled, and
> > repeating the recipe?
>
> Set breakpoint at
> xterm::8348
> C-z ; frame is hidden
> ;; I select again the hidden frame
> ;; gdb doesn't jump to the breakpoint and the frame is 'cursed'
> M-x
> ;; The frame wakes up and gdb reaches the breakpoint.
And if you apply your patch, do we get MapNotify immediately after
"selecting again the hidden frame"?
Btw, what does "selecting again the hidden frame" mean, exactly? What
gestures do you use to do that? And what is your window manager?
(Bhavin, can you answer these questions for your case as well?)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Fri, 07 Aug 2020 11:48:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 42655 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Set breakpoint at
>> xterm::8348
>> C-z ; frame is hidden
>> ;; I select again the hidden frame
>> ;; gdb doesn't jump to the breakpoint and the frame is 'cursed'
>> M-x
>> ;; The frame wakes up and gdb reaches the breakpoint.
>
> And if you apply your patch, do we get MapNotify immediately after
> "selecting again the hidden frame"?
No, I don't.
With the patch, I get MapNotify right after I hit `C-z'.
That seems to be OK when I start with `emacs -Q', but it doesn't help
if I start emacs loading my custom stuff.
> Btw, what does "selecting again the hidden frame" mean, exactly? What
> gestures do you use to do that? And what is your window manager?
[This seems to be a problem affecting only my window manager (GNOME Shell)]
- After C-z, the frame dissapear from the screen.
- Note, there is no lower/upper bar with the APP iconified.
- To get such a frame again, you can do it in several ways:
1. use shortcut to switch between apps (in my case M-TAB)
2. if you the current focused window is another Emacs frame, then you
can use the shortcut to switch between windows of same app
(in my case M-`)
3. Click upper-left corner menu 'Activities': now you can click in the
'iconified' frame with the mouse
Any of those 1-3 send the MapNotify
I have tested with other window managers in several OSes (Centos 8.1,
Ubuntu 18.04/20.04).
All window managers but GNOME Shell send the MapNotify
_right after_ you land in the previously iconified frame; that is, I only
can reproduce the bug when I am using GNOME Shell.
Desktop window-manager bug reproduced
KDE-plasma kWin No
MATE Metacity (Marco) No
Fluxbox Fluxbox No
GNOME Classic GNOME Shell Yes
GNOME in Wayland GNOME Shell Yes
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Fri, 07 Aug 2020 12:06:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 42655 <at> debbugs.gnu.org (full text, mbox):
> From: Tino Calancha <tino.calancha <at> gmail.com>
> Cc: 42655 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, uyennhi.qm <at> gmail.com,
> bhavin7392 <at> gmail.com, monnier <at> iro.umontreal.ca
> Date: Fri, 07 Aug 2020 13:47:42 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > And if you apply your patch, do we get MapNotify immediately after
> > "selecting again the hidden frame"?
> No, I don't.
> With the patch, I get MapNotify right after I hit `C-z'.
> That seems to be OK when I start with `emacs -Q', but it doesn't help
> if I start emacs loading my custom stuff.
So in your customized session the patch doesn't really solve the
problem? Or did I misunderstand?
> > Btw, what does "selecting again the hidden frame" mean, exactly? What
> > gestures do you use to do that? And what is your window manager?
>
> [This seems to be a problem affecting only my window manager (GNOME Shell)]
>
> - After C-z, the frame dissapear from the screen.
> - Note, there is no lower/upper bar with the APP iconified.
> - To get such a frame again, you can do it in several ways:
> 1. use shortcut to switch between apps (in my case M-TAB)
> 2. if you the current focused window is another Emacs frame, then you
> can use the shortcut to switch between windows of same app
> (in my case M-`)
> 3. Click upper-left corner menu 'Activities': now you can click in the
> 'iconified' frame with the mouse
> Any of those 1-3 send the MapNotify
Now I'm confused: if MapNotify is sent when you use any of the 3
methods, then why doesn't the frame redisplay normally? Previously
you said that MapNotify isn't received in this scenario. What am I
missing?
> I have tested with other window managers in several OSes (Centos 8.1,
> Ubuntu 18.04/20.04).
> All window managers but GNOME Shell send the MapNotify
> _right after_ you land in the previously iconified frame; that is, I only
> can reproduce the bug when I am using GNOME Shell.
OK, thanks. Bhavin, are you also using the same window manager?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Fri, 07 Aug 2020 12:22:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 42655 <at> debbugs.gnu.org (full text, mbox):
On Fri, 7 Aug 2020 at 17:35, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > I have tested with other window managers in several OSes (Centos 8.1,
> > Ubuntu 18.04/20.04).
> > All window managers but GNOME Shell send the MapNotify
> > _right after_ you land in the previously iconified frame; that is, I only
> > can reproduce the bug when I am using GNOME Shell.
>
> OK, thanks. Bhavin, are you also using the same window manager?
Yes, I'm using GNOME on Wayland too. And I hit M-TAB to return to Emacs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Fri, 07 Aug 2020 14:02:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 42655 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> So in your customized session the patch doesn't really solve the
> problem? Or did I misunderstand?
Exactly. My patches fixes _only_ an Emacs -Q session: for me,
it doesn't work in a normal custom session.
>> > Btw, what does "selecting again the hidden frame" mean, exactly? What
>> > gestures do you use to do that? And what is your window manager?
>>
>> [This seems to be a problem affecting only my window manager (GNOME Shell)]
>>
>> - After C-z, the frame dissapear from the screen.
>> - Note, there is no lower/upper bar with the APP iconified.
>> - To get such a frame again, you can do it in several ways:
>> 1. use shortcut to switch between apps (in my case M-TAB)
>> 2. if you the current focused window is another Emacs frame, then you
>> can use the shortcut to switch between windows of same app
>> (in my case M-`)
>> 3. Click upper-left corner menu 'Activities': now you can click in the
>> 'iconified' frame with the mouse
>> Any of those 1-3 send the MapNotify
>
> Now I'm confused: if MapNotify is sent when you use any of the 3
> methods, then why doesn't the frame redisplay normally?
Sorry, for the confusion. It redisplay normally in a `emacs -Q` session only.
> Previously
> you said that MapNotify isn't received in this scenario.
I have tested a rich casuistic: MapNotify is never recived in my 'custom
sessions'.
Following tables summarizes the situation:
=== window manager: GNOME Shell ===
--- unpatched Emacs-27 ---
emacs -Q custom libs
MapNotify at never never
bug? yes yes
--- Emacs-27 with patch ---
emacs -Q custom libs
MapNotify at iconify never
bug? no yes
=== window manager: Other than GNOME Shell ===
--- unpatched Emacs-27 ---
emacs -Q custom libs
MapNotify at de-iconify de-iconify
bug? no no
[In this case patched/unpatched makes no difference]
Except for GNOME Shell, for all win managers that I have tested,
the MapNotify comes always at the moment of de-iconify.
In Summary:
- The bugs happens when Emacs is compiled with Lucid and run in an
environment using GNOME Shell as window manager.
- The patch works for `emacs -Q`
- The patch doesn't work in my cursom sessions :-(
Possible workarounds for me right row:
1. Use a different window manager.
2. Or, compile Emacs with GTK.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Fri, 07 Aug 2020 15:08:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 42655 <at> debbugs.gnu.org (full text, mbox):
> From: Tino Calancha <tino.calancha <at> gmail.com>
> Cc: 42655 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, uyennhi.qm <at> gmail.com,
> bhavin7392 <at> gmail.com, monnier <at> iro.umontreal.ca
> Date: Fri, 07 Aug 2020 16:01:11 +0200
>
> Following tables summarizes the situation:
>
> === window manager: GNOME Shell ===
>
> --- unpatched Emacs-27 ---
> emacs -Q custom libs
>
> MapNotify at never never
> bug? yes yes
>
> --- Emacs-27 with patch ---
> emacs -Q custom libs
>
> MapNotify at iconify never
> bug? no yes
>
>
> === window manager: Other than GNOME Shell ===
>
> --- unpatched Emacs-27 ---
> emacs -Q custom libs
>
> MapNotify at de-iconify de-iconify
> bug? no no
Thanks.
Does anyone here have a clue why we don't get MapNotify in the GNOME
Shell case? I'm afraid I'm almost out of my depth here.
Tino, could you please use 'xev' to show which X events _are_ being
delivered to Emacs after you press M-TAB or do any of the other 2
gestures that are supposed to de-iconify the frame?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Sat, 08 Aug 2020 11:54:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 42655 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Does anyone here have a clue why we don't get MapNotify in the GNOME
> Shell case?
All window managers I have tested so far (except Gnome Shell) agree on the
following:
they send a 'VisibilityNotify event' when you select back the previously
iconified window.
Gnome Shell do not send such an event even when users choose 'Gnome
Classic', which uses a panel that displays the iconified apps.
[Design decision or Gnome bug? I haven't searched that much about this,
but I think gnome Shell should send that event as everyone else: this
migth affect other APPS, not only Emacs]
> Tino, could you please use 'xev' to show which X events _are_ being
> delivered to Emacs after you press M-TAB or do any of the other 2
> gestures that are supposed to de-iconify the frame?
Here is the comparison between window managers.
for easier navigations, I recommend to copy the
following lines and display it inside Emacs in a org mode buffer:
--8<-----------------------------cut here---------------start------------->8---
* xev: fluxbox
** C-z
KeyRelease event, serial 21, synthetic NO, window 0x1a00027,
root 0x215, subw 0x0, time 5924861, (981,179), root:(4949,427),
state 0x10, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 21, synthetic NO, window 0x1a00027,
root 0x215, subw 0x0, time 5924861, (981,179), root:(4949,427),
state 0x10, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 21, synthetic NO, window 0x1a00027,
root 0x215, subw 0x0, time 5925229, (981,179), root:(4949,427),
state 0x14, keycode 52 (keysym 0x7a, z), same_screen YES,
XLookupString gives 1 bytes: (1a) ""
XFilterEvent returns: False
KeyPress event, serial 21, synthetic NO, window 0x1a00027,
root 0x215, subw 0x0, time 5925229, (981,179), root:(4949,427),
state 0x14, keycode 52 (keysym 0x7a, z), same_screen YES,
XLookupString gives 1 bytes: (1a) ""
XmbLookupString gives 1 bytes: (1a) ""
XFilterEvent returns: False
PropertyNotify event, serial 21, synthetic NO, window 0x1a00027,
atom 0x1a8 (_NET_WM_ALLOWED_ACTIONS), time 5925236, state PropertyNewValue
PropertyNotify event, serial 22, synthetic NO, window 0x1a00027,
atom 0x19b (_NET_WM_STATE), time 5925237, state PropertyNewValue
FocusOut event, serial 23, synthetic NO, window 0x1a00027,
mode NotifyNormal, detail NotifyNonlinear
PropertyNotify event, serial 23, synthetic NO, window 0x1a00027,
atom 0x16d (WM_STATE), time 5925237, state PropertyNewValue
UnmapNotify event, serial 23, synthetic NO, window 0x1a00027,
event 0x1a00027, window 0x1a00027, from_configure NO
ConfigureNotify event, serial 24, synthetic YES, window 0x1a00027,
event 0x1a00027, window 0x1a00027, (3968,248), width 674, height 680,
border_width 0, above 0x0, override NO
** De-iconify (M-TAB, M-`, click w/ mouse, etc)
PropertyNotify event, serial 24, synthetic NO, window 0x1a00027,
atom 0x1a8 (_NET_WM_ALLOWED_ACTIONS), time 5996447, state PropertyNewValue
PropertyNotify event, serial 24, synthetic NO, window 0x1a00027,
atom 0x19b (_NET_WM_STATE), time 5996447, state PropertyDelete
MapNotify event, serial 24, synthetic NO, window 0x1a00027,
event 0x1a00027, window 0x1a00027, override NO
VisibilityNotify event, serial 24, synthetic NO, window 0x1a00027,
state VisibilityPartiallyObscured
PropertyNotify event, serial 24, synthetic NO, window 0x1a00027,
atom 0x16d (WM_STATE), time 5996449, state PropertyNewValue
VisibilityNotify event, serial 24, synthetic NO, window 0x1a00027,
state VisibilityUnobscured
FocusIn event, serial 24, synthetic NO, window 0x1a00027,
mode NotifyWhileGrabbed, detail NotifyNonlinear
KeymapNotify event, serial 24, synthetic NO, window 0x0,
keys: 109 0 4294967168 0 0 0 0 0 0 0 0 0 0 16 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ConfigureNotify event, serial 24, synthetic NO, window 0x1a00027,
event 0x1a00027, window 0x1a00027, (0,18), width 674, height 680,
border_width 0, above 0x400eb4, override NO
ConfigureNotify event, serial 24, synthetic YES, window 0x1a00027,
event 0x1a00027, window 0x1a00027, (3968,248), width 674, height 680,
border_width 0, above 0x0, override NO
FocusIn event, serial 24, synthetic NO, window 0x1a00027,
mode NotifyUngrab, detail NotifyAncestor
KeymapNotify event, serial 24, synthetic NO, window 0x0,
keys: 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
* xev: mate
** C-z
KeyRelease event, serial 19, synthetic NO, window 0x3c00028,
root 0x215, subw 0x0, time 1071389, (99,1997), root:(509,2158),
state 0x10, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 19, synthetic NO, window 0x3c00028,
root 0x215, subw 0x0, time 1071389, (99,1997), root:(509,2158),
state 0x10, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 22, synthetic NO, window 0x3c00028,
root 0x215, subw 0x0, time 1071805, (99,1997), root:(509,2158),
state 0x14, keycode 52 (keysym 0x7a, z), same_screen YES,
XLookupString gives 1 bytes: (1a) ""
XFilterEvent returns: False
KeyPress event, serial 22, synthetic NO, window 0x3c00028,
root 0x215, subw 0x0, time 1071805, (99,1997), root:(509,2158),
state 0x14, keycode 52 (keysym 0x7a, z), same_screen YES,
XLookupString gives 1 bytes: (1a) ""
XmbLookupString gives 1 bytes: (1a) ""
XFilterEvent returns: False
PropertyNotify event, serial 22, synthetic NO, window 0x3c00028,
atom 0x202 (_NET_WM_ALLOWED_ACTIONS), time 1071811, state PropertyNewValue
FocusOut event, serial 22, synthetic NO, window 0x3c00028,
mode NotifyNormal, detail NotifyNonlinear
UnmapNotify event, serial 22, synthetic NO, window 0x3c00028,
event 0x3c00028, window 0x3c00028, from_configure NO
PropertyNotify event, serial 22, synthetic NO, window 0x3c00028,
atom 0x1c0 (WM_STATE), time 1071812, state PropertyNewValue
PropertyNotify event, serial 22, synthetic NO, window 0x3c00028,
atom 0x17e (_NET_WM_STATE), time 1071812, state PropertyNewValue
PropertyNotify event, serial 24, synthetic NO, window 0x3c00028,
atom 0x17e (_NET_WM_STATE), time 1071813, state PropertyNewValue
** De-iconify (M-TAB, M-`, click w/ mouse, etc)
PropertyNotify event, serial 24, synthetic NO, window 0x3c00028,
atom 0x202 (_NET_WM_ALLOWED_ACTIONS), time 1140295, state PropertyNewValue
MapNotify event, serial 24, synthetic NO, window 0x3c00028,
event 0x3c00028, window 0x3c00028, override NO
VisibilityNotify event, serial 24, synthetic NO, window 0x3c00028,
state VisibilityUnobscured
PropertyNotify event, serial 24, synthetic NO, window 0x3c00028,
atom 0x1c0 (WM_STATE), time 1140303, state PropertyNewValue
PropertyNotify event, serial 24, synthetic NO, window 0x3c00028,
atom 0x17e (_NET_WM_STATE), time 1140303, state PropertyNewValue
FocusIn event, serial 24, synthetic NO, window 0x3c00028,
mode NotifyNormal, detail NotifyNonlinear
KeymapNotify event, serial 24, synthetic NO, window 0x0,
keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
PropertyNotify event, serial 24, synthetic NO, window 0x3c00028,
atom 0x17e (_NET_WM_STATE), time 1140305, state PropertyNewValue
* xev: plasma-wayland
** C-z
KeyRelease event, serial 19, synthetic NO, window 0x14000b5,
root 0x3a1, subw 0x0, time 364008, (-1280,444), root:(1025,698),
state 0x0, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 19, synthetic NO, window 0x14000b5,
root 0x3a1, subw 0x0, time 364008, (-1280,444), root:(1025,698),
state 0x0, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 22, synthetic NO, window 0x14000b5,
root 0x3a1, subw 0x0, time 364233, (-1280,444), root:(1025,698),
state 0x4, keycode 52 (keysym 0x7a, z), same_screen YES,
XLookupString gives 1 bytes: (1a) ""
XFilterEvent returns: False
KeyPress event, serial 22, synthetic NO, window 0x14000b5,
root 0x3a1, subw 0x0, time 364233, (-1280,444), root:(1025,698),
state 0x4, keycode 52 (keysym 0x7a, z), same_screen YES,
XLookupString gives 1 bytes: (1a) ""
XmbLookupString gives 1 bytes: (1a) ""
XFilterEvent returns: False
PropertyNotify event, serial 22, synthetic NO, window 0x14000b5,
atom 0x152 (_NET_WM_STATE), time 364234, state PropertyNewValue
FocusOut event, serial 22, synthetic NO, window 0x14000b5,
mode NotifyNormal, detail NotifyNonlinear
UnmapNotify event, serial 22, synthetic NO, window 0x14000b5,
event 0x14000b5, window 0x14000b5, from_configure NO
PropertyNotify event, serial 22, synthetic NO, window 0x14000b5,
atom 0x108 (WM_STATE), time 364235, state PropertyNewValue
PropertyNotify event, serial 22, synthetic NO, window 0x14000b5,
atom 0x152 (_NET_WM_STATE), time 364235, state PropertyNewValue
** De-iconify (M-TAB, M-`, click w/ mouse, etc)
PropertyNotify event, serial 23, synthetic NO, window 0x14000b5,
atom 0x152 (_NET_WM_STATE), time 387978, state PropertyNewValue
MapNotify event, serial 23, synthetic NO, window 0x14000b5,
event 0x14000b5, window 0x14000b5, override NO
VisibilityNotify event, serial 23, synthetic NO, window 0x14000b5,
state VisibilityUnobscured
PropertyNotify event, serial 23, synthetic NO, window 0x14000b5,
atom 0x108 (WM_STATE), time 387979, state PropertyNewValue
FocusIn event, serial 23, synthetic NO, window 0x14000b5,
mode NotifyNormal, detail NotifyNonlinear
KeymapNotify event, serial 23, synthetic NO, window 0x0,
keys: 4294967221 0 0 0 0 0 0 0 0 0 0 0 0 16 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
PropertyNotify event, serial 23, synthetic NO, window 0x14000b5,
atom 0x152 (_NET_WM_STATE), time 387986, state PropertyNewValue
* xev: gnome-shell-gnome-wayland
** C-z
KeyRelease event, serial 20, synthetic NO, window 0x8000ba,
root 0x3a0, subw 0x0, time 1658527, (-140,569), root:(873,742),
state 0x0, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 20, synthetic NO, window 0x8000ba,
root 0x3a0, subw 0x0, time 1658527, (-140,569), root:(873,742),
state 0x0, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 23, synthetic NO, window 0x8000ba,
root 0x3a0, subw 0x0, time 1658687, (-140,569), root:(873,742),
state 0x4, keycode 52 (keysym 0x7a, z), same_screen YES,
XLookupString gives 1 bytes: (1a) ""
XFilterEvent returns: False
KeyPress event, serial 23, synthetic NO, window 0x8000ba,
root 0x3a0, subw 0x0, time 1658687, (-140,569), root:(873,742),
state 0x4, keycode 52 (keysym 0x7a, z), same_screen YES,
XLookupString gives 1 bytes: (1a) ""
XmbLookupString gives 1 bytes: (1a) ""
XFilterEvent returns: False
PropertyNotify event, serial 23, synthetic NO, window 0x8000ba,
atom 0x12d (WM_STATE), time 1658695, state PropertyNewValue
PropertyNotify event, serial 23, synthetic NO, window 0x8000ba,
atom 0x10d (_NET_WM_STATE), time 1658695, state PropertyNewValue
PropertyNotify event, serial 23, synthetic NO, window 0x8000ba,
atom 0x193 (_GTK_EDGE_CONSTRAINTS), time 1658695, state PropertyNewValue
FocusOut event, serial 23, synthetic NO, window 0x8000ba,
mode NotifyNormal, detail NotifyNonlinear
PropertyNotify event, serial 23, synthetic NO, window 0x8000ba,
atom 0x10d (_NET_WM_STATE), time 1658695, state PropertyNewValue
PropertyNotify event, serial 23, synthetic NO, window 0x8000ba,
atom 0x193 (_GTK_EDGE_CONSTRAINTS), time 1658695, state PropertyNewValue
PropertyNotify event, serial 24, synthetic NO, window 0x8000ba,
atom 0x10d (_NET_WM_STATE), time 1658712, state PropertyNewValue
PropertyNotify event, serial 24, synthetic NO, window 0x8000ba,
atom 0x193 (_GTK_EDGE_CONSTRAINTS), time 1658712, state PropertyNewValue
** De-iconify (M-TAB, M-`, click w/ mouse, etc)
PropertyNotify event, serial 24, synthetic NO, window 0x8000ba,
atom 0x12d (WM_STATE), time 1703120, state PropertyNewValue
PropertyNotify event, serial 24, synthetic NO, window 0x8000ba,
atom 0x10d (_NET_WM_STATE), time 1703120, state PropertyNewValue
PropertyNotify event, serial 24, synthetic NO, window 0x8000ba,
atom 0x193 (_GTK_EDGE_CONSTRAINTS), time 1703120, state PropertyNewValue
FocusIn event, serial 24, synthetic NO, window 0x8000ba,
mode NotifyNormal, detail NotifyNonlinear
KeymapNotify event, serial 24, synthetic NO, window 0x0,
keys: 13 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
PropertyNotify event, serial 24, synthetic NO, window 0x8000ba,
atom 0x10d (_NET_WM_STATE), time 1703123, state PropertyNewValue
PropertyNotify event, serial 24, synthetic NO, window 0x8000ba,
atom 0x193 (_GTK_EDGE_CONSTRAINTS), time 1703123, state PropertyNewValue
PropertyNotify event, serial 24, synthetic NO, window 0x8000ba,
atom 0x10d (_NET_WM_STATE), time 1703145, state PropertyNewValue
PropertyNotify event, serial 24, synthetic NO, window 0x8000ba,
atom 0x193 (_GTK_EDGE_CONSTRAINTS), time 1703145, state PropertyNewValue
* xev: gnome-shell-gnome-classic
** C-z
KeyRelease event, serial 23, synthetic NO, window 0x22000ba,
root 0x215, subw 0x0, time 609608, (-1390,576), root:(783,764),
state 0x0, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 23, synthetic NO, window 0x22000ba,
root 0x215, subw 0x0, time 609608, (-1390,576), root:(783,764),
state 0x0, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 23, synthetic NO, window 0x22000ba,
root 0x215, subw 0x0, time 609768, (-1390,576), root:(783,764),
state 0x4, keycode 52 (keysym 0x7a, z), same_screen YES,
XLookupString gives 1 bytes: (1a) ""
XFilterEvent returns: False
KeyPress event, serial 23, synthetic NO, window 0x22000ba,
root 0x215, subw 0x0, time 609768, (-1390,576), root:(783,764),
state 0x4, keycode 52 (keysym 0x7a, z), same_screen YES,
XLookupString gives 1 bytes: (1a) ""
XmbLookupString gives 1 bytes: (1a) ""
XFilterEvent returns: False
PropertyNotify event, serial 23, synthetic NO, window 0x22000ba,
atom 0x1bb (WM_STATE), time 609783, state PropertyNewValue
PropertyNotify event, serial 23, synthetic NO, window 0x22000ba,
atom 0x17e (_NET_WM_STATE), time 609783, state PropertyNewValue
PropertyNotify event, serial 23, synthetic NO, window 0x22000ba,
atom 0x1ca (_GTK_EDGE_CONSTRAINTS), time 609783, state PropertyNewValue
FocusOut event, serial 23, synthetic NO, window 0x22000ba,
mode NotifyNormal, detail NotifyNonlinear
PropertyNotify event, serial 24, synthetic NO, window 0x22000ba,
atom 0x17e (_NET_WM_STATE), time 609788, state PropertyNewValue
PropertyNotify event, serial 24, synthetic NO, window 0x22000ba,
atom 0x1ca (_GTK_EDGE_CONSTRAINTS), time 609788, state PropertyNewValue
** De-iconify (M-TAB, M-`, click w/ mouse, etc)
PropertyNotify event, serial 24, synthetic NO, window 0x22000ba,
atom 0x1bb (WM_STATE), time 657505, state PropertyNewValue
PropertyNotify event, serial 24, synthetic NO, window 0x22000ba,
atom 0x17e (_NET_WM_STATE), time 657505, state PropertyNewValue
PropertyNotify event, serial 24, synthetic NO, window 0x22000ba,
atom 0x1ca (_GTK_EDGE_CONSTRAINTS), time 657505, state PropertyNewValue
FocusIn event, serial 24, synthetic NO, window 0x22000ba,
mode NotifyWhileGrabbed, detail NotifyNonlinear
KeymapNotify event, serial 24, synthetic NO, window 0x0,
keys: 126 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
FocusIn event, serial 24, synthetic NO, window 0x22000ba,
mode NotifyUngrab, detail NotifyNonlinear
KeymapNotify event, serial 24, synthetic NO, window 0x0,
keys: 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
PropertyNotify event, serial 24, synthetic NO, window 0x22000ba,
atom 0x17e (_NET_WM_STATE), time 657520, state PropertyNewValue
PropertyNotify event, serial 24, synthetic NO, window 0x22000ba,
atom 0x1ca (_GTK_EDGE_CONSTRAINTS), time 657520, state PropertyNewValue
--8<-----------------------------cut here---------------end--------------->8---
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Sun, 09 Aug 2020 14:27:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 42655 <at> debbugs.gnu.org (full text, mbox):
> From: Tino Calancha <tino.calancha <at> gmail.com>
> Cc: 42655 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, uyennhi.qm <at> gmail.com,
> bhavin7392 <at> gmail.com, monnier <at> iro.umontreal.ca
> Date: Sat, 08 Aug 2020 13:52:53 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Does anyone here have a clue why we don't get MapNotify in the GNOME
> > Shell case?
> All window managers I have tested so far (except Gnome Shell) agree on the
> following:
>
> they send a 'VisibilityNotify event' when you select back the previously
> iconified window.
Our code expects MapNotify. My reading of the code in xterm.c is that
we do nothing special when we receive VisibilityNotify.
I see in xterm.c that we already have some special treatment of the
Gnome Shell, see below. Could you please put a breakpoint there, and
tell why we don't set the frame's visible flag and don't reset its
iconified flag when the PropertyNotify event is received? Your event
log seems to indicate we get quite a few of PropertyNotify events when
the frame is de-iconified.
> Here is the comparison between window managers.
> for easier navigations, I recommend to copy the
> following lines and display it inside Emacs in a org mode buffer:
Thanks, this is very useful.
Here's the snippet from xterm.c that deals with PropertyNotify:
case PropertyNotify:
x_display_set_last_user_time (dpyinfo, event->xproperty.time);
f = x_top_window_to_frame (dpyinfo, event->xproperty.window);
if (f && event->xproperty.atom == dpyinfo->Xatom_net_wm_state)
{
bool not_hidden = x_handle_net_wm_state (f, &event->xproperty);
if (not_hidden && FRAME_ICONIFIED_P (f))
{
/* 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;
XSETFRAME (inev.ie.frame_or_window, f);
}
else if (! not_hidden && ! FRAME_ICONIFIED_P (f))
{
SET_FRAME_VISIBLE (f, 0);
SET_FRAME_ICONIFIED (f, true);
inev.ie.kind = ICONIFY_EVENT;
XSETFRAME (inev.ie.frame_or_window, f);
}
}
x_handle_property_notify (&event->xproperty);
xft_settings_event (dpyinfo, event);
goto OTHER;
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Mon, 10 Aug 2020 17:53:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 42655 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
CC Daniel whom might have some ideas.
A bit of context.
Some WMs (e.g. Mutter in Gnome Shell or Muffin) follow a new trend: they
don't unmap windows when they are iconified.
https://gitlab.gnome.org/GNOME/mutter/-/issues/185
Since they are never unmapped, the windows are not mapped back when they
are deconified. This might cause an unresponsive frame in Lucid Emacs
builds, because we redisplay when we get the MapNotify signal
(that we don't receive in those WMs).
Apparentely, GTK3 Emacs builds are not affected by this issue.
> I see in xterm.c that we already have some special treatment of the
> Gnome Shell, see below. Could you please put a breakpoint there, and
> tell why we don't set the frame's visible flag and don't reset its
> iconified flag when the PropertyNotify event is received? Your event
> log seems to indicate we get quite a few of PropertyNotify events when
> the frame is de-iconified.
That break point is only reached while creating the frame or clicking
the menu bars. Once the frame is created, I am not able to reach that
part by minimize/unminimize.
I have printed out `event->type` right before the switch(event->type)
I enter the break point at PropertyNotify when `event->type` equals 28.
The xev utility is printing out PropertyNotify for a bunch of different
values of `event->type`, not just for 28.
Naively, I can workaround this issue by checking for an iconified frame at
FocusIn: this fixes this issue in both `emacs -Q` and my
custom Emacs session.
I am not sure if this is a convenient way. We might also want to make
it more specific for checking some condition.
--8<-----------------------------cut here---------------start------------->8---
commit d9b06705a045336e1ef307cdfd523a1d5cbb9e7a
Author: Tino Calancha <ccalancha <at> suse.com>
Date: Mon Aug 10 19:32:17 2020 +0200
Fix bug 42655
Some WMs (e.g. mutter in Gnome Shell) don't unmap iconized windows,
thus we won't get a MapNotify when deconifying them.
Check if we are deconifying a window elsewhere.
- src/xterm.c (handle_one_xevent):
Check for window deconify when receiving a FocusIn signal.
diff --git a/src/xterm.c b/src/xterm.c
index 6340700cb8..de1da2d4d4 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -8760,6 +8760,19 @@ handle_one_xevent (struct x_display_info *dpyinfo,
goto OTHER;
case FocusIn:
+ /* 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 deconizing a window (Bug42655). */
+ 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;
--8<-----------------------------cut here---------------end--------------->8---
In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.21, cairo version 1.16.0)
of 2020-08-09 built on localhost.example.com
Repository revision: dcce2b57bb91d490787dffd437b61196f1029b41
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: openSUSE Tumbleweed
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#42655; Package
emacs.
(Wed, 12 Aug 2020 16:51:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 42655 <at> debbugs.gnu.org (full text, mbox):
> From: Tino Calancha <tino.calancha <at> gmail.com>
> Cc: 42655 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, uyennhi.qm <at> gmail.com,
> bhavin7392 <at> gmail.com, monnier <at> iro.umontreal.ca, dancol <at> dancol.org
> Date: Mon, 10 Aug 2020 19:52:39 +0200
>
> > I see in xterm.c that we already have some special treatment of the
> > Gnome Shell, see below. Could you please put a breakpoint there, and
> > tell why we don't set the frame's visible flag and don't reset its
> > iconified flag when the PropertyNotify event is received? Your event
> > log seems to indicate we get quite a few of PropertyNotify events when
> > the frame is de-iconified.
> That break point is only reached while creating the frame or clicking
> the menu bars. Once the frame is created, I am not able to reach that
> part by minimize/unminimize.
>
> I have printed out `event->type` right before the switch(event->type)
> I enter the break point at PropertyNotify when `event->type` equals 28.
> The xev utility is printing out PropertyNotify for a bunch of different
> values of `event->type`, not just for 28.
>
>
> Naively, I can workaround this issue by checking for an iconified frame at
> FocusIn: this fixes this issue in both `emacs -Q` and my
> custom Emacs session.
That would be my next idea, so please go ahead and install this. And
thanks for all the footwork in investigating this issue.
> + /* 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 deconizing a window (Bug42655). */
Please M-q in this comment, to make its lines shorter.
Reply sent
to
Tino Calancha <tino.calancha <at> gmail.com>:
You have taken responsibility.
(Sat, 15 Aug 2020 14:24:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Tino Calancha <tino.calancha <at> gmail.com>:
bug acknowledged by developer.
(Sat, 15 Aug 2020 14:24:02 GMT)
Full text and
rfc822 format available.
Message #121 received at 42655-done <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Naively, I can workaround this issue by checking for an iconified frame at
>> FocusIn: this fixes this issue in both `emacs -Q` and my
>> custom Emacs session.
>
> That would be my next idea, so please go ahead and install this. And
> thanks for all the footwork in investigating this issue.
Thank you for your guidance. It was crucial.
Pushed fix into emacs-27 branch as commit
'Prevent from frozen frame after `C-z' in Lucid builds'
(3c4edfd85ee8f49e40715a400a1fc65950e07482)
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 13 Sep 2020 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 225 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.