GNU bug report logs - #78980
31.0.50; C-z crashes emacsclient -nw

Previous Next

Full log

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 78980 <at> debbugs.gnu.org, Pip Cet <pipcet <at> protonmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#78980: 31.0.50; C-z crashes emacsclient -nw
Date: Thu, 10 Jul 2025 11:35:41 +0200

martin rudalics <rudalics <at> gmx.at> writes:

>> Maybe one could pack all that in a new function, say
>> is_display_optimizable that one would use instead of
>> is_tty_root_frame_with_visible_children? For tty frames It could check
>> that the frame is not an invisible root, and then check for visible
>> chldren.
>
> When I originally wrote the code for GUIs (on X and WINDOWS) I simply
> relied on the promise made by the system designers that the window
> manager will handle child frames as advertised.  Evaluate the following
> forms in a row:
>
> (setq frame1 (selected-frame))
> (setq frame2 (make-frame `((parent-frame . ,frame1) (top . 40) (left . 40)
> 			   (width . 40) (height . 30))))
> (setq frame3 (make-frame `((parent-frame . ,frame2) (top . 40) (left . 40)
> 			   (width . 20) (height . 15))))
> (make-frame-invisible frame2)
>
> On each GUI I know of, the last form will make frame3 invisible without
> Emacs contributing anything to it.   Making frame2 visible again will
> also make frame3 visible.  Making frame3 invisible before making frame2
> invisible and making frame2 visible again will leave frame3 invisible.
>
> According to what I read, an exception should be made for modal frames.
> Hence if frame3 were a modal frame, it could be visible even if frame2
> (or frame1) aren't.  But we do not have an interface for making our own
> modal frames so I cannot check this.  Here any modal GUI windows are
> likely child windows of the root and behave like popup menus - as long
> as they are visible you cannot access any other window.
>
> In either case, this means that the window manager and/or the toolkit
> have to keep internally their own copy of the Emacs frame tree and
> handle visibility autonomously.  On a TTY we have to (or probably
> should) emulate that behavior ourselves.

I think one thing you are saying is that we should leave any checks for
visibility of GUI frames, as far as redisplay is concerned, as-is,
right? That is basically don't check.

That leaves the decision where to implement the "WM" functionality in
the tty case, and what that functionality should be.

Form my POV, redisplay_internal is the place where to put that because
that's the only "central place" in redisplay.

The functionality on GUIs sounds like we should have something like
  
  bool is_displayed(struct frame *f) {
      // Öeave window system frames alone
      if (!is_tty_frame(f))
          return true;
      // Don't display if not marked visible.
      if (!FRAME_VISIBLE_P(f))
          return false;
      // If marked visible but parent isn't displayed
      const struct frame *oarent = FRAME_PARENT_FRAME(f);
      return parent ? is_displayed(parent) : true;
  }

WDYT?

Previous Next

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