bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm windowmanager seems to get lost after first use.

bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm windowmanager seems to get lost after first use.

[Jos de Kloe]

After migrating from emacs 27.2 to emacs 28-1 (default versions in 
Fedora 35 and Fedora 36) I observe a strange behavior for the C-z 
key-binding.
It only occurs if I use fvwm as windowmanager (which is still X11 
based), and is absent if I use xfce in stead.

For emacs 27-2 all works as intended and C-z will let the emacs window 
iconify. And double clicking the iconified emacs will raise it again. No 
problems here.

But for emacs 28-1 the C-z command works only once. If I raise emacs and 
try again to issue C-z it does not iconify, but looses focus in stead.
Also after regaining focus by moving the mouse out and back in to the 
emacs window, C-z does not return to its intended behavior.

I tested with the standard Fedora versions:
    emacs-1:27.2-9.fc35.x86_64
    emacs-1:28.1-2.fc36.x86_64
on a Fedora 36 workstation installation.

I also tested this by downloading the emacs sources for versions 27-2 
and 28-1 and compiling it myself, and the situation does not change. The 
bug is present in version 28-1 and absent in version 27.2.
So there is no relation to the Fedora packaging process. It really seems 
to be a bug inside emacs itself.




In GNU Emacs 28.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 
3.24.34, cairo version 1.17.6)
  of 2022-07-15 built on buildhw-x86-02.iad2.fedoraproject.org
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Fedora Linux 36 (Workstation Edition)

Configured using:
  'configure --build=x86_64-redhat-linux-gnu
  --host=x86_64-redhat-linux-gnu --program-prefix=
  --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
  --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
  --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
  --libexecdir=/usr/libexec --localstatedir=/var
  --sharedstatedir=/var/lib --mandir=/usr/share/man
  --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
  --with-rsvg --with-tiff --with-xpm --with-x-toolkit=gtk3 --with-gpm=no
  --with-xwidgets --with-modules --with-harfbuzz --with-cairo --with-json
  --with-native-compilation build_alias=x86_64-redhat-linux-gnu
  host_alias=x86_64-redhat-linux-gnu CC=gcc 'CFLAGS=-DMAIL_USE_LOCKF -O2
  -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
  -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
  -Wp,-D_GLIBCXX_ASSERTIONS
  -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
  -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
  -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
  LDFLAGS=-Wl,-z,relro
  PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM XWIDGETS GTK3 ZLIB

Important settings:
   value of $LANG: en_US.UTF-8
   value of $XMODIFIERS: @im=none
   locale-coding-system: utf-8-unix

Major mode: Text

Minor modes in effect:
   tooltip-mode: t
   global-eldoc-mode: t
   show-paren-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
   indent-tabs-mode: t
   transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map 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
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode 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 lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax 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 emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads
xwidget-internal dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo move-toolbar gtk x-toolkit x multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 68513 5974)
  (symbols 48 6648 2)
  (strings 32 19711 2609)
  (string-bytes 1 675049)
  (vectors 16 14175)
  (vector-slots 8 300265 11315)
  (floats 8 22 33)
  (intervals 56 272 0)
  (buffers 992 12))

-- 
*******************************************************
   dr. J. de Kloe
   jos.de.kloe@knmi.nl  kloedej@knmi.nl
*******************************************************

bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm windowmanager seems to get lost after first use.

[Eli Zaretskii]

> Date: Thu, 29 Sep 2022 16:32:39 +0200
> From: Jos de Kloe <kloe0040@planet.nl>
> 
> But for emacs 28-1 the C-z command works only once. If I raise emacs and 
> try again to issue C-z it does not iconify, but looses focus in stead.
> Also after regaining focus by moving the mouse out and back in to the 
> emacs window, C-z does not return to its intended behavior.

What does "C-h l" say after you press C-z and see the problematic
behavior?

bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm windowmanager seems to get lost after first use.

[Jos de Kloe]

This is the output I get:

  <down> ;; next-line
  C-z	;; suspend-frame
  C-z	;; suspend-frame
  C-h l	;; view-lossage


On 9/29/22 19:41, Eli Zaretskii wrote:
>> Date: Thu, 29 Sep 2022 16:32:39 +0200
>> From: Jos de Kloe <kloe0040@planet.nl>
>>
>> But for emacs 28-1 the C-z command works only once. If I raise emacs and
>> try again to issue C-z it does not iconify, but looses focus in stead.
>> Also after regaining focus by moving the mouse out and back in to the
>> emacs window, C-z does not return to its intended behavior.
> 
> What does "C-h l" say after you press C-z and see the problematic
> behavior?

bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm windowmanager seems to get lost after first use.

[Eli Zaretskii]

> Date: Fri, 30 Sep 2022 08:45:33 +0200
> Cc: 58164@debbugs.gnu.org
> From: Jos de Kloe <kloe0040@planet.nl>
> 
> This is the output I get:
> 
>   <down> ;; next-line
>   C-z	;; suspend-frame
>   C-z	;; suspend-frame
>   C-h l	;; view-lossage

So I guess the problem is in the X iconify_frame_hook, which is
x_iconify_frame.  If you can step through that function in a debugger
and see what's going on there, it might help.  Maybe Emacs thinks the
frame is already iconified, and thus does nothing?

Thanks.

bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm windowmanager seems to get lost after first use.

[Jos de Kloe]

Yes I can run emacs in gdb, but I am not sure what to look at. Can you 
suggest which variables I should inspect?

On 9/30/22 08:58, Eli Zaretskii wrote:
>> Date: Fri, 30 Sep 2022 08:45:33 +0200
>> Cc: 58164@debbugs.gnu.org
>> From: Jos de Kloe <kloe0040@planet.nl>
>>
>> This is the output I get:
>>
>>    <down> ;; next-line
>>    C-z	;; suspend-frame
>>    C-z	;; suspend-frame
>>    C-h l	;; view-lossage
> 
> So I guess the problem is in the X iconify_frame_hook, which is
> x_iconify_frame.  If you can step through that function in a debugger
> and see what's going on there, it might help.  Maybe Emacs thinks the
> frame is already iconified, and thus does nothing?
> 
> Thanks.

bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm windowmanager seems to get lost after first use.

[Jos de Kloe]

Just stepping through the instructions in this x_iconify_frame function 
I see the following happening:

first time I hit C-z:

Thread 1 "emacs" hit Breakpoint 1, x_iconify_frame (f=0xe46c70) at 
xterm.c:11976
11976   {
(gdb) n
11982     if (FRAME_DISPLAY_INFO (f)->highlight_frame == f)
(gdb) n
11983       FRAME_DISPLAY_INFO (f)->highlight_frame = 0;
(gdb) n
11985     if (FRAME_ICONIFIED_P (f))
(gdb) n
11988     block_input ();
(gdb) n
11990     gui_set_bitmap_icon (f);
(gdb) n
11993     if (FRAME_GTK_OUTER_WIDGET (f))
(gdb) n
11995         if (! FRAME_VISIBLE_P (f))
(gdb) n
11998         gtk_window_iconify (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)));
(gdb) n
11999         SET_FRAME_VISIBLE (f, 0);
(gdb) n
12000         SET_FRAME_ICONIFIED (f, true);
(gdb) n
12001         unblock_input ();
(gdb) n
12002         return;

second time I hit C-z:

Thread 1 "emacs" hit Breakpoint 1, x_iconify_frame (f=0xe46c70) at 
xterm.c:11976
11976   {
(gdb) n
11982     if (FRAME_DISPLAY_INFO (f)->highlight_frame == f)
(gdb) n
11983       FRAME_DISPLAY_INFO (f)->highlight_frame = 0;
(gdb) n
11985     if (FRAME_ICONIFIED_P (f))
(gdb) n
Ffuncall (nargs=1, args=args@entry=0x7fffffffd258) at eval.c:3048
3048      lisp_eval_depth--;
(gdb) n
3049      if (backtrace_debug_on_exit (specpdl + count))
(gdb) n
3051      specpdl_ptr--;
(gdb) n
3052      return val;
(gdb) n

I hope this helps to zoom in on the problem.

On 9/30/22 08:58, Eli Zaretskii wrote:
>> Date: Fri, 30 Sep 2022 08:45:33 +0200
>> Cc: 58164@debbugs.gnu.org
>> From: Jos de Kloe <kloe0040@planet.nl>
>>
>> This is the output I get:
>>
>>    <down> ;; next-line
>>    C-z	;; suspend-frame
>>    C-z	;; suspend-frame
>>    C-h l	;; view-lossage
> 
> So I guess the problem is in the X iconify_frame_hook, which is
> x_iconify_frame.  If you can step through that function in a debugger
> and see what's going on there, it might help.  Maybe Emacs thinks the
> frame is already iconified, and thus does nothing?
> 
> Thanks.

bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm windowmanager seems to get lost after first use.

[Eli Zaretskii]

> Date: Mon, 3 Oct 2022 08:37:06 +0200
> Cc: 58164@debbugs.gnu.org
> From: Jos de Kloe <kloe0040@planet.nl>
> 
> second time I hit C-z:
> 
> Thread 1 "emacs" hit Breakpoint 1, x_iconify_frame (f=0xe46c70) at 
> xterm.c:11976
> 11976   {
> (gdb) n
> 11982     if (FRAME_DISPLAY_INFO (f)->highlight_frame == f)
> (gdb) n
> 11983       FRAME_DISPLAY_INFO (f)->highlight_frame = 0;
> (gdb) n
> 11985     if (FRAME_ICONIFIED_P (f))
> (gdb) n
> Ffuncall (nargs=1, args=args@entry=0x7fffffffd258) at eval.c:3048
> 3048      lisp_eval_depth--;
> (gdb) n
> 3049      if (backtrace_debug_on_exit (specpdl + count))
> (gdb) n
> 3051      specpdl_ptr--;
> (gdb) n
> 3052      return val;
> (gdb) n
> 
> I hope this helps to zoom in on the problem.

It gives a hint.  Can you type "bt" before you type "n" here:

> 11985     if (FRAME_ICONIFIED_P (f))
> (gdb) n

and show the resulting backtrace?  Also, type "bt" _after_ you type
"n" there and see this line:

> Ffuncall (nargs=1, args=args@entry=0x7fffffffd258) at eval.c:3048
> 3048      lisp_eval_depth--;

You see, FRAME_ICONIFIED_P doesn't call Ffuncall, and there's no such
call anywhere in sight inside x_iconify_frame.  So either the macro
FRAME_ICONIFIED_P somehow signaled an error (which I don't think can
happen), or something else kicked us out of the function when we tried
to see if the frame is already iconified.  The question is: what did
kick us out and why?

bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm windowmanager seems to get lost after first use.

[Jos de Kloe]

On 10/3/22 18:47, Eli Zaretskii wrote:
>> Date: Mon, 3 Oct 2022 08:37:06 +0200
>> Cc: 58164@debbugs.gnu.org
>> From: Jos de Kloe <kloe0040@planet.nl>
>>
>> second time I hit C-z:
>>
>> Thread 1 "emacs" hit Breakpoint 1, x_iconify_frame (f=0xe46c70) at
>> xterm.c:11976
>> 11976   {
>> (gdb) n
>> 11982     if (FRAME_DISPLAY_INFO (f)->highlight_frame == f)
>> (gdb) n
>> 11983       FRAME_DISPLAY_INFO (f)->highlight_frame = 0;
>> (gdb) n
>> 11985     if (FRAME_ICONIFIED_P (f))
>> (gdb) n
>> Ffuncall (nargs=1, args=args@entry=0x7fffffffd258) at eval.c:3048
>> 3048      lisp_eval_depth--;
>> (gdb) n
>> 3049      if (backtrace_debug_on_exit (specpdl + count))
>> (gdb) n
>> 3051      specpdl_ptr--;
>> (gdb) n
>> 3052      return val;
>> (gdb) n
>>
>> I hope this helps to zoom in on the problem.
> 
> It gives a hint.  Can you type "bt" before you type "n" here:
> 
>> 11985     if (FRAME_ICONIFIED_P (f))
>> (gdb) n
> 
> and show the resulting backtrace?  Also, type "bt" _after_ you type
> "n" there and see this line:

before:

Thread 1 "emacs" hit Breakpoint 1, x_iconify_frame (f=0xe293e0) at 
xterm.c:11976
11976   {
(gdb) n
11982     if (FRAME_DISPLAY_INFO (f)->highlight_frame == f)
(gdb) n
11983       FRAME_DISPLAY_INFO (f)->highlight_frame = 0;
(gdb) bt
#0  x_iconify_frame (f=0xe293e0) at xterm.c:11983
#1  0x0000000000428191 in Ficonify_frame (frame=0x0) at frame.c:2811
#2  0x00000000005683b2 in funcall_subr
     (subr=0x989340 <Siconify_frame>, numargs=numargs@entry=0, 
args=args@entry=0x7fffffffd260) at eval.c:3098
#3  0x0000000000566d80 in Ffuncall (nargs=1, args=args@entry=0x7fffffffd258)
     at eval.c:3023
#4  0x000000000059a50a in exec_byte_code
     (bytestr=0x7ffff1aea90c, vector=<optimized out>, 
maxdepth=<optimized out>, args_template=args_template@entry=0x2, 
nargs=nargs@entry=0, args=<optimized out>,
     args@entry=0x7fffffffd400) at bytecode.c:632
#5  0x0000000000569541 in fetch_and_exec_byte_code
     (args=0x7fffffffd400, nargs=0, syms_left=0x2, fun=0x7ffff1aea8a5)
     at /home/jos/temp_emacs/emacs-28.1/src/lisp.h:1853
#6  funcall_lambda
     (fun=0x7ffff1aea8a5, nargs=nargs@entry=0, 
arg_vector=arg_vector@entry=0x7fffffffd400)
     at eval.c:3228
#7  0x0000000000566d69 in Ffuncall (nargs=1, args=args@entry=0x7fffffffd3f8)
     at eval.c:3027
#8  0x000000000059a50a in exec_byte_code
     (bytestr=0x7ffff1aea94c, vector=<optimized out>, 
maxdepth=<optimized out>, args_template=args_template@entry=0x2, 
nargs=nargs@entry=0, args=<optimized out>,
     args@entry=0x7fffffffd7b0) at bytecode.c:632
#9  0x0000000000569541 in fetch_and_exec_byte_code
     (args=0x7fffffffd7b0, nargs=0, syms_left=0x2, fun=0x7ffff1aea7a5)
     at /home/jos/temp_emacs/emacs-28.1/src/lisp.h:1853
#10 funcall_lambda
     (fun=0x7ffff1aea7a5, nargs=nargs@entry=0, 
arg_vector=arg_vector@entry=0x7fffffffd7b0)
     at eval.c:3228
#11 0x0000000000566d69 in Ffuncall (nargs=nargs@entry=1, 
args=args@entry=0x7fffffffd7a8)
     at eval.c:3027
#12 0x0000000000563b8f in Ffuncall_interactively (nargs=1, 
args=0x7fffffffd7a8)
#13 0x0000000000568388 in funcall_subr
     (subr=0x996740 <Sfuncall_interactively>, numargs=numargs@entry=1, 
args=args@entry=0x7fffffffd7a8) at eval.c:3078
#14 0x0000000000566d80 in Ffuncall (nargs=nargs@entry=2, 
args=args@entry=0x7fffffffd7a0)
     at eval.c:3023
#15 0x0000000000567098 in Fapply (nargs=nargs@entry=3, 
args=args@entry=0x7fffffffd7a0)
     at eval.c:2606
#16 0x00000000005640fa in Fcall_interactively
     (function=0x7ffff10e1250, record_flag=0x0, keys=0x7ffff1e7eae5) at 
callint.c:353
#17 0x00000000005683d8 in funcall_subr
     (subr=0x996700 <Scall_interactively>, numargs=numargs@entry=3, 
args=args@entry=0x7fffffffd900) at eval.c:3103
#18 0x0000000000566d80 in Ffuncall (nargs=4, args=args@entry=0x7fffffffd8f8)
     at eval.c:3023
#19 0x000000000059a50a in exec_byte_code
     (bytestr=0x7ffff186486c, vector=<optimized out>, 
maxdepth=<optimized out>, args_template=args_template@entry=0x1006, 
nargs=nargs@entry=1, args=<optimized out>,
     args@entry=0x7fffffffdb48) at bytecode.c:632
#20 0x0000000000569541 in fetch_and_exec_byte_code
     (args=0x7fffffffdb48, nargs=1, syms_left=0x1006, fun=0x7ffff18644a5)
     at /home/jos/temp_emacs/emacs-28.1/src/lisp.h:1853
#21 funcall_lambda
     (fun=0x7ffff18644a5, nargs=nargs@entry=1, 
arg_vector=arg_vector@entry=0x7fffffffdb48)
     at eval.c:3228
#22 0x0000000000566d69 in Ffuncall (nargs=nargs@entry=2, 
args=args@entry=0x7fffffffdb40)
     at eval.c:3027
#23 0x0000000000566f19 in call1 (fn=fn@entry=0x4590, arg1=<optimized 
out>) at eval.c:2883
#24 0x0000000000502a36 in command_loop_1 () at keyboard.c:1505
#25 0x000000000056612d in internal_condition_case
     (bfun=bfun@entry=0x5023eb <command_loop_1>, 
handlers=handlers@entry=0x90, hfun=hfun@entry=0x4f7da1 <cmd_error>) at 
eval.c:1450
#26 0x00000000004f4841 in command_loop_2 (handlers=handlers@entry=0x90)
     at keyboard.c:1133
#27 0x00000000005660a4 in internal_catch
     (tag=tag@entry=0xe850, func=func@entry=0x4f482b <command_loop_2>, 
arg=arg@entry=0x90)
     at eval.c:1181
#28 0x00000000004f480d in command_loop () at keyboard.c:1111
#29 0x00000000004f7a2e in recursive_edit_1 () at keyboard.c:720
#30 0x00000000004f7cf9 in Frecursive_edit () at keyboard.c:803
#31 0x00000000004f3d72 in main (argc=3, argv=0x7fffffffdfd8) at emacs.c:2354


and after:

(gdb) n
11985     if (FRAME_ICONIFIED_P (f))
(gdb) bt
#0  x_iconify_frame (f=0xe293e0) at xterm.c:11985
#1  0x0000000000428191 in Ficonify_frame (frame=0x0) at frame.c:2811
#2  0x00000000005683b2 in funcall_subr
     (subr=0x989340 <Siconify_frame>, numargs=numargs@entry=0, 
args=args@entry=0x7fffffffd260) at eval.c:3098
#3  0x0000000000566d80 in Ffuncall (nargs=1, args=args@entry=0x7fffffffd258)
     at eval.c:3023
#4  0x000000000059a50a in exec_byte_code
     (bytestr=0x7ffff1aea90c, vector=<optimized out>, 
maxdepth=<optimized out>, args_template=args_template@entry=0x2, 
nargs=nargs@entry=0, args=<optimized out>,
     args@entry=0x7fffffffd400) at bytecode.c:632
#5  0x0000000000569541 in fetch_and_exec_byte_code
     (args=0x7fffffffd400, nargs=0, syms_left=0x2, fun=0x7ffff1aea8a5)
     at /home/jos/temp_emacs/emacs-28.1/src/lisp.h:1853
#6  funcall_lambda
     (fun=0x7ffff1aea8a5, nargs=nargs@entry=0, 
arg_vector=arg_vector@entry=0x7fffffffd400)
     at eval.c:3228
#7  0x0000000000566d69 in Ffuncall (nargs=1, args=args@entry=0x7fffffffd3f8)
     at eval.c:3027
#8  0x000000000059a50a in exec_byte_code
     (bytestr=0x7ffff1aea94c, vector=<optimized out>, 
maxdepth=<optimized out>, args_template=args_template@entry=0x2, 
nargs=nargs@entry=0, args=<optimized out>,
     args@entry=0x7fffffffd7b0) at bytecode.c:632
#9  0x0000000000569541 in fetch_and_exec_byte_code
     (args=0x7fffffffd7b0, nargs=0, syms_left=0x2, fun=0x7ffff1aea7a5)
     at /home/jos/temp_emacs/emacs-28.1/src/lisp.h:1853
#10 funcall_lambda
     (fun=0x7ffff1aea7a5, nargs=nargs@entry=0, 
arg_vector=arg_vector@entry=0x7fffffffd7b0)
     at eval.c:3228
#11 0x0000000000566d69 in Ffuncall (nargs=nargs@entry=1, 
args=args@entry=0x7fffffffd7a8)
     at eval.c:3027
#12 0x0000000000563b8f in Ffuncall_interactively (nargs=1, 
args=0x7fffffffd7a8)
     at callint.c:260
#13 0x0000000000568388 in funcall_subr
     (subr=0x996740 <Sfuncall_interactively>, numargs=numargs@entry=1, 
args=args@entry=0x7fffffffd7a8) at eval.c:3078
#14 0x0000000000566d80 in Ffuncall (nargs=nargs@entry=2, 
args=args@entry=0x7fffffffd7a0)
     at eval.c:3023
#15 0x0000000000567098 in Fapply (nargs=nargs@entry=3, 
args=args@entry=0x7fffffffd7a0)
     at eval.c:2606
#16 0x00000000005640fa in Fcall_interactively
     (function=0x7ffff10e1250, record_flag=0x0, keys=0x7ffff1e7eae5) at 
callint.c:353
#17 0x00000000005683d8 in funcall_subr
     (subr=0x996700 <Scall_interactively>, numargs=numargs@entry=3, 
args=args@entry=0x7fffffffd900) at eval.c:3103
#18 0x0000000000566d80 in Ffuncall (nargs=4, args=args@entry=0x7fffffffd8f8)
     at eval.c:3023
#19 0x000000000059a50a in exec_byte_code
     (bytestr=0x7ffff186486c, vector=<optimized out>, 
maxdepth=<optimized out>, args_template=args_template@entry=0x1006, 
nargs=nargs@entry=1, args=<optimized out>,
     args@entry=0x7fffffffdb48) at bytecode.c:632
#20 0x0000000000569541 in fetch_and_exec_byte_code
     (args=0x7fffffffdb48, nargs=1, syms_left=0x1006, fun=0x7ffff18644a5)
     at /home/jos/temp_emacs/emacs-28.1/src/lisp.h:1853
#21 funcall_lambda
     (fun=0x7ffff18644a5, nargs=nargs@entry=1, 
arg_vector=arg_vector@entry=0x7fffffffdb48)
     at eval.c:3228
#22 0x0000000000566d69 in Ffuncall (nargs=nargs@entry=2, 
args=args@entry=0x7fffffffdb40)
     at eval.c:3027
#23 0x0000000000566f19 in call1 (fn=fn@entry=0x4590, arg1=<optimized 
out>) at eval.c:2883
#24 0x0000000000502a36 in command_loop_1 () at keyboard.c:1505
#25 0x000000000056612d in internal_condition_case
     (bfun=bfun@entry=0x5023eb <command_loop_1>, 
handlers=handlers@entry=0x90, hfun=hfun@entry=0x4f7da1 <cmd_error>) at 
eval.c:1450
#26 0x00000000004f4841 in command_loop_2 (handlers=handlers@entry=0x90)
     at keyboard.c:1133
#27 0x00000000005660a4 in internal_catch
     (tag=tag@entry=0xe850, func=func@entry=0x4f482b <command_loop_2>, 
arg=arg@entry=0x90)
     at eval.c:1181
#28 0x00000000004f480d in command_loop () at keyboard.c:1111
#29 0x00000000004f7a2e in recursive_edit_1 () at keyboard.c:720
#30 0x00000000004f7cf9 in Frecursive_edit () at keyboard.c:803
#31 0x00000000004f3d72 in main (argc=3, argv=0x7fffffffdfd8) at emacs.c:2354



>> Ffuncall (nargs=1, args=args@entry=0x7fffffffd258) at eval.c:3048
>> 3048      lisp_eval_depth--;
> 
> You see, FRAME_ICONIFIED_P doesn't call Ffuncall, and there's no such
> call anywhere in sight inside x_iconify_frame.  So either the macro
> FRAME_ICONIFIED_P somehow signaled an error (which I don't think can
> happen), or something else kicked us out of the function when we tried
> to see if the frame is already iconified.  The question is: what did
> kick us out and why?

bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm windowmanager seems to get lost after first use.

[Eli Zaretskii]

> Date: Mon, 3 Oct 2022 19:39:20 +0200
> Cc: 58164@debbugs.gnu.org
> From: Jos de Kloe <kloe0040@planet.nl>
> 
> and after:
> 
> (gdb) n
> 11985     if (FRAME_ICONIFIED_P (f))
> (gdb) bt

Thanks, but I meant "after" here:

> Ffuncall (nargs=1, args=args@entry=0x7fffffffd258) at eval.c:3048
> 3048      lisp_eval_depth--;

That is, after you step over the "if (FRAME_ICONIFIED_P (f))" line and
end up in Ffuncall.

But I think I see the reason: indeed Emacs thinks that the frame is
still iconified, so it does nothing and returns.

So I guess some X event that was supposed to arrive and tell us that
the frame is no longer iconified didn't arrive or something?  I hope
Po Lu will be able to look into this soon.

bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm windowmanager seems to get lost after first use.

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 3 Oct 2022 19:39:20 +0200
>> Cc: 58164@debbugs.gnu.org
>> From: Jos de Kloe <kloe0040@planet.nl>
>> 
>> and after:
>> 
>> (gdb) n
>> 11985     if (FRAME_ICONIFIED_P (f))
>> (gdb) bt
>
> Thanks, but I meant "after" here:
>
>> Ffuncall (nargs=1, args=args@entry=0x7fffffffd258) at eval.c:3048
>> 3048      lisp_eval_depth--;
>
> That is, after you step over the "if (FRAME_ICONIFIED_P (f))" line and
> end up in Ffuncall.
>
> But I think I see the reason: indeed Emacs thinks that the frame is
> still iconified, so it does nothing and returns.
>
> So I guess some X event that was supposed to arrive and tell us that
> the frame is no longer iconified didn't arrive or something?  I hope
> Po Lu will be able to look into this soon.

Thanks, I will look into this bug.

bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm windowmanager seems to get lost after first use.

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu <luangruo@yahoo.com> writes:

> Thanks, I will look into this bug.

Should be fixed now on the master branch.  Jos, could you please see if
the problem has been resolved for you as well?

bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm windowmanager seems to get lost after first use.

[Jos de Kloe]

Yes, I can confirm that the master branch solves the issue on my side. 
Iconify works again as intended, also after several iconify/de-iconify 
actions.

Thanks a lot for your support !


On 10/4/22 03:25, Po Lu wrote:
> Po Lu <luangruo@yahoo.com> writes:
> 
>> Thanks, I will look into this bug.
> 
> Should be fixed now on the master branch.  Jos, could you please see if
> the problem has been resolved for you as well?

bug#58164: 28.1; keybinding C-z to suspend-frame in fvwm windowmanager seems to get lost after first use.

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Jos de Kloe <kloe0040@planet.nl> writes:

> Yes, I can confirm that the master branch solves the issue on my
> side. Iconify works again as intended, also after several
> iconify/de-iconify actions.
>
> Thanks a lot for your support !

Thanks, closing.