GNU bug report logs - #28611
26.0.60; iconifying a child frame seems to be problematic

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28611 in the body.
You can then email your comments to 28611 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.60; iconifying a child frame seems to be problematic
Date: Wed, 27 Sep 2017 10:49:08 +0900

Steps to reproduce:

  1. $ emacs -Q &
  2. Enlarge the frame a bit by mouse.
  3. Type (make-frame `((parent-frame . ,(selected-frame)))) C-j
  4. Click the newly created child frame.
  5. Type (iconify-frame) C-j

Result:

  The child frame becomes unresponsive.
  The parent frame can take input, but the cursor is still hollow.

Maybe an attempt to iconify a child frame should cause an error.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

In GNU Emacs 26.0.60 (build 1, x86_64-apple-darwin16.7.0, X toolkit, Xaw3d scroll bars)
 of 2017-09-27 built on YAMAMOTO-no-iMac-5K.local
Repository revision: a3f647c5c810e8be5321bf99cb21d565590a7cf8
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --without-ns --with-jpeg=no --with-gif=no --with-tiff=no
 --with-gnutls=no PKG_CONFIG=/opt/local/bin/pkg-config
 PKG_CONFIG_PATH=/usr/lib/pkgconfig:/opt/X11/lib/pkgconfig:/usr/local/lib/pkgconfig
 PKG_CONFIG_LIBDIR='

Configured features:
XAW3D XPM PNG NOTIFY ACL LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS LUCID X11

Important settings:
  value of $LANG: ja_JP.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 subr-x puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util japan-util 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 menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame 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 minibuffer
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 kqueue dynamic-setting
font-render-setting x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 97322 7132)
 (symbols 48 20135 1)
 (miscs 40 54 86)
 (strings 32 28850 1995)
 (string-bytes 1 740494)
 (vectors 16 14679)
 (vector-slots 8 566966 11070)
 (floats 8 51 65)
 (intervals 56 250 13)
 (buffers 992 12))

Message #8 received at 28611 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>, 28611 <at> debbugs.gnu.org
Subject: Re: bug#28611: 26.0.60;
 iconifying a child frame seems to be problematic
Date: Wed, 27 Sep 2017 10:13:13 +0200

> Steps to reproduce:
>
>    1. $ emacs -Q &
>    2. Enlarge the frame a bit by mouse.
>    3. Type (make-frame `((parent-frame . ,(selected-frame)))) C-j
>    4. Click the newly created child frame.
>    5. Type (iconify-frame) C-j
>
> Result:
>
>    The child frame becomes unresponsive.
>    The parent frame can take input, but the cursor is still hollow.
>
> Maybe an attempt to iconify a child frame should cause an error.

We warn about this in the Elisp manual:

   * The semantics of maximizing and iconifying child frames is highly
     window-system dependent.  As a rule, applications should never
     invoke these operations for child frames.

I'm not sure whether we should do more about this given the fact that
these operations may and should work well on other window systems.

BTW: Does ‘make-frame-visible’ invoked for the child frame make it
responsive again?

martin

Message #11 received at 28611 <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 28611 <at> debbugs.gnu.org
Subject: Re: bug#28611: 26.0.60;
 iconifying a child frame seems to be problematic
Date: Wed, 27 Sep 2017 18:21:10 +0900

>>>>> On Wed, 27 Sep 2017 10:13:13 +0200, martin rudalics <rudalics <at> gmx.at> said:

>> Steps to reproduce:
>> 
>> 1. $ emacs -Q &
>> 2. Enlarge the frame a bit by mouse.
>> 3. Type (make-frame `((parent-frame . ,(selected-frame)))) C-j
>> 4. Click the newly created child frame.
>> 5. Type (iconify-frame) C-j
>> 
>> Result:
>> 
>> The child frame becomes unresponsive.
>> The parent frame can take input, but the cursor is still hollow.
>> 
>> Maybe an attempt to iconify a child frame should cause an error.

> We warn about this in the Elisp manual:

>     * The semantics of maximizing and iconifying child frames is highly
>       window-system dependent.  As a rule, applications should never
>       invoke these operations for child frames.

I've overlooked that.  Thanks for the info.

> I'm not sure whether we should do more about this given the fact that
> these operations may and should work well on other window systems.

I think at least C-z should iconify the top-level frame so users may
not confuse.

> BTW: Does ‘make-frame-visible’ invoked for the child frame make it
> responsive again?

Yes.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

Message #14 received at 28611 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 28611 <at> debbugs.gnu.org
Subject: Re: bug#28611: 26.0.60;
 iconifying a child frame seems to be problematic
Date: Fri, 29 Sep 2017 10:32:50 +0200

> I think at least C-z should iconify the top-level frame so users may
> not confuse.

I think you're right.  Maybe I'll also add some customizations to allow
‘iconify-frame’ to alternatively act on the parent, the top level frame
(the default probably), make the frame invisible, or do nothing at all.
And provide something similar for maximizations.

Thanks, martin

Message #17 received at 28611 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 28611 <at> debbugs.gnu.org
Subject: Re: bug#28611: 26.0.60;
 iconifying a child frame seems to be problematic
Date: Sun, 01 Oct 2017 10:24:18 +0200

>  > I think at least C-z should iconify the top-level frame so users may
>  > not confuse.
>
> I think you're right.  Maybe I'll also add some customizations to allow
> ‘iconify-frame’ to alternatively act on the parent, the top level frame
> (the default probably), make the frame invisible, or do nothing at all.

Done now - please have a look.

> And provide something similar for maximizations.

Deferred until someone reports bad behavior in this area.

Thanks for the suggestion, martin

Message #22 received at 28611-done <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 28611-done <at> debbugs.gnu.org
Subject: Re: bug#28611: 26.0.60;
 iconifying a child frame seems to be problematic
Date: Mon, 02 Oct 2017 09:55:10 +0900

>>>>> On Sun, 01 Oct 2017 10:24:18 +0200, martin rudalics <rudalics <at> gmx.at> said:

>> > I think at least C-z should iconify the top-level frame so users
>> > may not confuse.
>> 
>> I think you're right.  Maybe I'll also add some customizations to
>> allow ‘iconify-frame’ to alternatively act on the parent, the top
>> level frame (the default probably), make the frame invisible, or do
>> nothing at all.

> Done now - please have a look.

It looks nice.  Thanks.  Closing the bug.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

Message #25 received at 28611 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 28611 <at> debbugs.gnu.org, YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#28611: 26.0.60;
 iconifying a child frame seems to be problematic
Date: Mon, 02 Oct 2017 13:27:52 -0400

Hi,

b03b4f6d7 causes without-x builds to fail:

frame.c:2545:25: error: 'struct frame' has no member named 'parent_frame'
   Lisp_Object parent = f->parent_frame;

Ref eg https://hydra.nixos.org/build/62198700

Message #28 received at 28611-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: rudalics <at> gmx.at, 28611-done <at> debbugs.gnu.org
Subject: Re: bug#28611: 26.0.60;
 iconifying a child frame seems to be problematic
Date: Mon, 02 Oct 2017 21:37:06 +0300

> From: Glenn Morris <rgm <at> gnu.org>
> Date: Mon, 02 Oct 2017 13:27:52 -0400
> Cc: 28611 <at> debbugs.gnu.org
> 
> b03b4f6d7 causes without-x builds to fail:
> 
> frame.c:2545:25: error: 'struct frame' has no member named 'parent_frame'
>    Lisp_Object parent = f->parent_frame;

Thanks, fixed.

Message #31 received at 28611-done <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Glenn Morris <rgm <at> gnu.org>
Cc: 28611-done <at> debbugs.gnu.org
Subject: Re: bug#28611: 26.0.60;
 iconifying a child frame seems to be problematic
Date: Tue, 03 Oct 2017 11:15:16 +0200

>> b03b4f6d7 causes without-x builds to fail:
>>
>> frame.c:2545:25: error: 'struct frame' has no member named 'parent_frame'
>>     Lisp_Object parent = f->parent_frame;
>
> Thanks, fixed.

Many thanks to Glenn for the report and to you for the fix.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.