GNU bug report logs - #76031
31.0.50; Switching frames on TTY display doesn't work

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 76031 in the body.
You can then email your comments to 76031 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: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Switching frames on TTY display doesn't work
Date: Mon, 03 Feb 2025 19:23:06 +0200

To reproduce:

  emacs -Q -nw
  C-x 5 f src/xdisp.c RET
  C-x 5 o

The last step should have switched back to frame F1 showing the
*scratch* buffer, but instead it does nothing, showing the frame F2 as
before.

Perhaps related, "M-x select-frame-by-name" insists that the only
frame to switch to is the currently selected frame F2; if you try to
type "F1" at the prompt, you get "No match".

This report is from GNU/Linux, but I also see this on MS-Windows, so
it is not platform-specific, it seems.

In GNU Emacs 31.0.50 (build 145, x86_64-pc-linux-gnu, GTK+ Version
 3.24.33, cairo version 1.16.0) of 2025-02-03 built on
 maintain0p.gnu.org
Repository revision: 1639ad2814ae100c9f878a1388eb9ffc9d208b07
Repository branch: master
System Description: Trisquel GNU/Linux Aramo (11.0.1)

Configured using:
 'configure --with-gif=ifavailable --with-tiff=ifavailable
 --with-jpeg=ifavailable --with-xpm=ifavailable
 --without-native-compilation --enable-checking=yes,glyphs 'CFLAGS=-O2
 -g3''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM XRANDR GTK3
ZLIB

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: C/*l

Minor modes in effect:
  bug-reference-prog-mode: t
  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
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils vc-git diff-mode
track-changes easy-mmode files-x vc vc-dispatcher bug-reference
thingatpt cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs time-date subr-x cl-loaddefs cl-lib term/xterm
xterm byte-opt gv bytecomp byte-compile rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen
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 nadvice seq
simple cl-generic indonesian philippine 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 abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo gtk x-toolkit xinput2 x multi-tty move-toolbar
make-network-process tty-child-frames emacs)

Memory information:
((conses 16 88939 11577) (symbols 48 8846 0) (strings 32 23202 1908)
 (string-bytes 1 728563) (vectors 16 12123)
 (vector-slots 8 109442 5360) (floats 8 32 346) (intervals 56 3766 0)
 (buffers 984 11))

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Mon, 03 Feb 2025 20:20:51 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> To reproduce:
>
>   emacs -Q -nw
>   C-x 5 f src/xdisp.c RET
>   C-x 5 o
>
> The last step should have switched back to frame F1 showing the
> *scratch* buffer, but instead it does nothing, showing the frame F2 as
> before.
>
> Perhaps related, "M-x select-frame-by-name" insists that the only
> frame to switch to is the currently selected frame F2; if you try to
> type "F1" at the prompt, you get "No match".
>
> This report is from GNU/Linux, but I also see this on MS-Windows, so
> it is not platform-specific, it seems.

I see this too on macOS, with Martin's latest diff installed.

It seems C-x 5 o only works among root and children now. An interesting
question would be which way we want it to work. I mean when there are
children. In which way would one switch to the next root frame?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: rudalics <at> gmx.at, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Mon, 03 Feb 2025 22:05:40 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: 76031 <at> debbugs.gnu.org,  martin rudalics <rudalics <at> gmx.at>
> Date: Mon, 03 Feb 2025 20:20:51 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > To reproduce:
> >
> >   emacs -Q -nw
> >   C-x 5 f src/xdisp.c RET
> >   C-x 5 o
> >
> > The last step should have switched back to frame F1 showing the
> > *scratch* buffer, but instead it does nothing, showing the frame F2 as
> > before.
> >
> > Perhaps related, "M-x select-frame-by-name" insists that the only
> > frame to switch to is the currently selected frame F2; if you try to
> > type "F1" at the prompt, you get "No match".
> >
> > This report is from GNU/Linux, but I also see this on MS-Windows, so
> > it is not platform-specific, it seems.
> 
> I see this too on macOS, with Martin's latest diff installed.
> 
> It seems C-x 5 o only works among root and children now. An interesting
> question would be which way we want it to work. I mean when there are
> children. In which way would one switch to the next root frame?

I think it should work in the order of next-frame.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Cc: 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Tue, 4 Feb 2025 09:09:48 +0100

> It seems C-x 5 o only works among root and children now. An interesting
> question would be which way we want it to work. I mean when there are
> children. In which way would one switch to the next root frame?

The same way we do that on GUIs now.  Switch to any frame unless
it has 'no-other-frame' set:

‘no-other-frame’
     If this is non-‘nil’, then this frame is not eligible as candidate
     for the functions ‘next-frame’, ‘previous-frame’ (*note Finding All
     Frames::) and ‘other-frame’, see *note (emacs)Frame Commands::.

martin

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Tue, 04 Feb 2025 09:46:32 +0100

[Message part 1 (text/plain, inline)]

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

>> It seems C-x 5 o only works among root and children now. An interesting
>> question would be which way we want it to work. I mean when there are
>> children. In which way would one switch to the next root frame?
>
> The same way we do that on GUIs now.  Switch to any frame unless
> it has 'no-other-frame' set:
>
> ‘no-other-frame’
>      If this is non-‘nil’, then this frame is not eligible as candidate
>      for the functions ‘next-frame’, ‘previous-frame’ (*note Finding All
>      Frames::) and ‘other-frame’, see *note (emacs)Frame Commands::.
>
> martin

This patch fixes it for me:

[0001-Fix-min-width-display-spec-handling-bug-76014.patch (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: gerd.moellmann <at> gmail.com, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Tue, 04 Feb 2025 16:25:27 +0200

> Date: Tue, 4 Feb 2025 09:09:48 +0100
> Cc: 76031 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > It seems C-x 5 o only works among root and children now. An interesting
>  > question would be which way we want it to work. I mean when there are
>  > children. In which way would one switch to the next root frame?
> 
> The same way we do that on GUIs now.

Maybe I'm missing something, but "C-x 5 o" works for me on GUI frames
as expected.  If I repeat the recipe of this bug in a GUI session,
there's no problem, and "C-x 5 o" switches to the other frame.

> Switch to any frame unless it has 'no-other-frame' set:
> 
> ‘no-other-frame’
>       If this is non-‘nil’, then this frame is not eligible as candidate
>       for the functions ‘next-frame’, ‘previous-frame’ (*note Finding All
>       Frames::) and ‘other-frame’, see *note (emacs)Frame Commands::.

How does this come into play in the recipe I posted.  Those were
ordinary frames, and I hope 'no-other-frame' is by default nil.

What am I missing?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: rudalics <at> gmx.at, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Tue, 04 Feb 2025 16:26:58 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  76031 <at> debbugs.gnu.org
> Date: Tue, 04 Feb 2025 09:46:32 +0100
> 
> martin rudalics <rudalics <at> gmx.at> writes:
> 
> >> It seems C-x 5 o only works among root and children now. An interesting
> >> question would be which way we want it to work. I mean when there are
> >> children. In which way would one switch to the next root frame?
> >
> > The same way we do that on GUIs now.  Switch to any frame unless
> > it has 'no-other-frame' set:
> >
> > ‘no-other-frame’
> >      If this is non-‘nil’, then this frame is not eligible as candidate
> >      for the functions ‘next-frame’, ‘previous-frame’ (*note Finding All
> >      Frames::) and ‘other-frame’, see *note (emacs)Frame Commands::.
> >
> > martin
> 
> This patch fixes it for me:

Ehm.. wrong patch?  You attached the patch for the min-width thingy.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Tue, 04 Feb 2025 15:30:42 +0100

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> Ehm.. wrong patch?  You attached the patch for the min-width thingy.

Sorry, here's the right one

[0001-Don-t-skip-tty-root-frames-in-other-frame-bug-76031.patch (text/x-patch, attachment)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Tue, 4 Feb 2025 15:49:38 +0100

>>   > It seems C-x 5 o only works among root and children now. An interesting
>>   > question would be which way we want it to work. I mean when there are
>>   > children. In which way would one switch to the next root frame?
>>
>> The same way we do that on GUIs now.
>
> Maybe I'm missing something, but "C-x 5 o" works for me on GUI frames
> as expected.  If I repeat the recipe of this bug in a GUI session,
> there's no problem, and "C-x 5 o" switches to the other frame.
>
>> Switch to any frame unless it has 'no-other-frame' set:
>>
>> ‘no-other-frame’
>>        If this is non-‘nil’, then this frame is not eligible as candidate
>>        for the functions ‘next-frame’, ‘previous-frame’ (*note Finding All
>>        Frames::) and ‘other-frame’, see *note (emacs)Frame Commands::.
>
> How does this come into play in the recipe I posted.  Those were
> ordinary frames, and I hope 'no-other-frame' is by default nil.
>
> What am I missing?

Gerd asked above: "I mean when there are children. In which way would
one switch to the next root frame?"  And the answer is do it the way we
use on GUI frames already - give child frames a non-nil "no-other-frame"
parameter.

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Cc: 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Tue, 4 Feb 2025 16:06:10 +0100

> Sorry, here's the right one

This doesn't fix 'next-frame'.  See Eli's example with M-x
select-frame-by-name which calls (next-frame nil 0).

You then probably want to fix the

  else if (EQ (frames, Qvisible))
    /* If FRAMES is 'visible', ignore invisible frames.  */
    return FRAME_VISIBLE_P (c) ? candidate : Qnil;

check in candidate_frame for the case where c is a tty frame (and the
subsequent "0" case).

I doubt this can fixed in an ad hoc manner.  The semantics of
FRAME_VISIBLE_P must be resolved first in a way that 'frame-visible-p'
will hold only for frames that can be chosen via the 'visible' argument
of these functions and vice versa.

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: gerd.moellmann <at> gmail.com, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Tue, 04 Feb 2025 18:19:55 +0200

> Date: Tue, 4 Feb 2025 16:06:10 +0100
> Cc: 76031 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > Sorry, here's the right one
> 
> This doesn't fix 'next-frame'.  See Eli's example with M-x
> select-frame-by-name which calls (next-frame nil 0).
> 
> You then probably want to fix the
> 
>    else if (EQ (frames, Qvisible))
>      /* If FRAMES is 'visible', ignore invisible frames.  */
>      return FRAME_VISIBLE_P (c) ? candidate : Qnil;
> 
> check in candidate_frame for the case where c is a tty frame (and the
> subsequent "0" case).
> 
> I doubt this can fixed in an ad hoc manner.  The semantics of
> FRAME_VISIBLE_P must be resolved first in a way that 'frame-visible-p'
> will hold only for frames that can be chosen via the 'visible' argument
> of these functions and vice versa.

Can someone tell what change(s) broke this?  AFAIU, child frames were
not supposed to change the way next-frame works.  What part of those
changes had that effect?

Aren't child frames just like normal frames as far as next-frame
etc. are concerned?  If not, why not?

Or was the problem caused by frame visibility changes?  So a frame
that is not the top TTY frame on its display is considered "invisible"
now, and so next-frame refuses to pick it up, is that the problem?

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Tue, 4 Feb 2025 18:54:16 +0100

> Or was the problem caused by frame visibility changes?  So a frame
> that is not the top TTY frame on its display is considered "invisible"
> now, and so next-frame refuses to pick it up, is that the problem?

Yes.  I tried to explain that a number of times but failed miserably.

martin

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Tue, 04 Feb 2025 19:27:40 +0100

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

>> Or was the problem caused by frame visibility changes?  So a frame
>> that is not the top TTY frame on its display is considered "invisible"
>> now, and so next-frame refuses to pick it up, is that the problem?
>
> Yes.  I tried to explain that a number of times but failed miserably.
>

That could be understood wrong. With emacs -q -nw in master, after C-x 5
2:

  (selected-frame)
  #<frame F2 0x135810158>
  (next-frame)
  #<frame F1 0x156019200>
  (frame-visible-p (next-frame))
  nil

For C-x 5 o, it's other-frame that filters out F1, not next-frame. It
didn't before because F1 was considered "obscured", internally, but
considered visible for Lisp. I removed that because it was confusing to
work with.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Tue, 04 Feb 2025 19:31:20 +0100

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

>> Sorry, here's the right one
>
> This doesn't fix 'next-frame'.  See Eli's example with M-x
> select-frame-by-name which calls (next-frame nil 0).
>
> You then probably want to fix the
>
>   else if (EQ (frames, Qvisible))
>     /* If FRAMES is 'visible', ignore invisible frames.  */
>     return FRAME_VISIBLE_P (c) ? candidate : Qnil;
>
> check in candidate_frame for the case where c is a tty frame (and the
> subsequent "0" case).
>
> I doubt this can fixed in an ad hoc manner.  The semantics of
> FRAME_VISIBLE_P must be resolved first in a way that 'frame-visible-p'
> will hold only for frames that can be chosen via the 'visible' argument
> of these functions and vice versa.

The semantics of being visible before I removed being obscured was
confusing. A frame could be visible but obscured, which is for me means
it's invisible and can't be seen. That makes no sense to me.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: rudalics <at> gmx.at, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Tue, 04 Feb 2025 22:10:48 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  76031 <at> debbugs.gnu.org
> Date: Tue, 04 Feb 2025 19:27:40 +0100
> 
> martin rudalics <rudalics <at> gmx.at> writes:
> 
> >> Or was the problem caused by frame visibility changes?  So a frame
> >> that is not the top TTY frame on its display is considered "invisible"
> >> now, and so next-frame refuses to pick it up, is that the problem?
> >
> > Yes.  I tried to explain that a number of times but failed miserably.
> >
> 
> That could be understood wrong. With emacs -q -nw in master, after C-x 5
> 2:
> 
>   (selected-frame)
>   #<frame F2 0x135810158>
>   (next-frame)
>   #<frame F1 0x156019200>
>   (frame-visible-p (next-frame))
>   nil
> 
> For C-x 5 o, it's other-frame that filters out F1, not next-frame. It
> didn't before because F1 was considered "obscured", internally, but
> considered visible for Lisp. I removed that because it was confusing to
> work with.

Martin was talking about select-frame-by-name, which uses
make-frame-names-alist to create a list of frames from which it offers
to select.  And make-frame-names-alist uses next-frame with 2nd
argument 0, which does:

      else if (FIXNUMP (minibuf) && XFIXNUM (minibuf) == 0)
	{
	  if (FRAME_VISIBLE_P (c) || FRAME_ICONIFIED_P (c))
	    return candidate;
	}

So now this skips all the non-child TTY frames except the top frame,
and that makes no sense to me.

I think there's a conceptual problem here: the meaning of "invisible"
on TTY is different from its meaning on GUI displays.  On GUI display,
"invisible" means the frame is not on display at all, whereas on TTY
the frame is there, it's just obscured by the one(s) above it.  So I
think we need to change candidate_frame to consider TTY frames
"visible" for the purpose of returning "visible" frames in next_frame
and prev_frame.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: rudalics <at> gmx.at, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Tue, 04 Feb 2025 22:13:14 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  76031 <at> debbugs.gnu.org
> Date: Tue, 04 Feb 2025 19:31:20 +0100
> 
> martin rudalics <rudalics <at> gmx.at> writes:
> 
> >> Sorry, here's the right one
> >
> > This doesn't fix 'next-frame'.  See Eli's example with M-x
> > select-frame-by-name which calls (next-frame nil 0).
> >
> > You then probably want to fix the
> >
> >   else if (EQ (frames, Qvisible))
> >     /* If FRAMES is 'visible', ignore invisible frames.  */
> >     return FRAME_VISIBLE_P (c) ? candidate : Qnil;
> >
> > check in candidate_frame for the case where c is a tty frame (and the
> > subsequent "0" case).
> >
> > I doubt this can fixed in an ad hoc manner.  The semantics of
> > FRAME_VISIBLE_P must be resolved first in a way that 'frame-visible-p'
> > will hold only for frames that can be chosen via the 'visible' argument
> > of these functions and vice versa.
> 
> The semantics of being visible before I removed being obscured was
> confusing. A frame could be visible but obscured, which is for me means
> it's invisible and can't be seen. That makes no sense to me.

But nothing else makes sense on TTY when we have multiple frames on
the same display.  So for the purpose of switching frames, the
meaning of "visible" on TTY should be tweaked to produce the expected
effect.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: gerd.moellmann <at> gmail.com, rudalics <at> gmx.at
Cc: 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Tue, 04 Feb 2025 22:22:09 +0200

> Cc: rudalics <at> gmx.at, 76031 <at> debbugs.gnu.org
> Date: Tue, 04 Feb 2025 22:10:48 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> I think there's a conceptual problem here: the meaning of "invisible"
> on TTY is different from its meaning on GUI displays.  On GUI display,
> "invisible" means the frame is not on display at all, whereas on TTY
> the frame is there, it's just obscured by the one(s) above it.  So I
> think we need to change candidate_frame to consider TTY frames
> "visible" for the purpose of returning "visible" frames in next_frame
> and prev_frame.

IOW, "invisible" here does not mean literally "not visible", it means
something very specialized and specific to frames on GUI displays.
Because, for example, a GUI frame obscured by another one is not
treated as "invisible", is it?  And a frame that is iconified is also
not treated as "invisible", although it cannot be seen.

So maybe we should resurrect the "obscured" state for TTY frames after
all?

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Tue, 04 Feb 2025 21:31:14 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> I think there's a conceptual problem here: the meaning of "invisible"
> on TTY is different from its meaning on GUI displays.  On GUI display,
> "invisible" means the frame is not on display at all, whereas on TTY
> the frame is there, it's just obscured by the one(s) above it.  So I

How is such a frame that was previously marked "obscured" still "on
display" as you write? It's literally not on display on the terminal.

> think we need to change candidate_frame to consider TTY frames
> "visible" for the purpose of returning "visible" frames in next_frame
> and prev_frame.

Please read my other mail, where I show that next-frame currently
returns the root frame in question, it's other-frame that skips it.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Tue, 04 Feb 2025 21:32:44 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: rudalics <at> gmx.at, 76031 <at> debbugs.gnu.org
>> Date: Tue, 04 Feb 2025 22:10:48 +0200
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> 
>> I think there's a conceptual problem here: the meaning of "invisible"
>> on TTY is different from its meaning on GUI displays.  On GUI display,
>> "invisible" means the frame is not on display at all, whereas on TTY
>> the frame is there, it's just obscured by the one(s) above it.  So I
>> think we need to change candidate_frame to consider TTY frames
>> "visible" for the purpose of returning "visible" frames in next_frame
>> and prev_frame.
>
> IOW, "invisible" here does not mean literally "not visible", it means
> something very specialized and specific to frames on GUI displays.
> Because, for example, a GUI frame obscured by another one is not
> treated as "invisible", is it?  And a frame that is iconified is also
> not treated as "invisible", although it cannot be seen.
>
> So maybe we should resurrect the "obscured" state for TTY frames after
> all?

I'm against this, obviously.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Tue, 04 Feb 2025 21:34:20 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> The semantics of being visible before I removed being obscured was
>> confusing. A frame could be visible but obscured, which is for me means
>> it's invisible and can't be seen. That makes no sense to me.
>
> But nothing else makes sense on TTY when we have multiple frames on
> the same display.  So for the purpose of switching frames, the
> meaning of "visible" on TTY should be tweaked to produce the expected
> effect.

This can be done on other-frame and maybe elsewhere in Lisp, as I showed
in my patch.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: rudalics <at> gmx.at, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Wed, 05 Feb 2025 05:27:46 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: rudalics <at> gmx.at,  76031 <at> debbugs.gnu.org
> Date: Tue, 04 Feb 2025 21:34:20 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> The semantics of being visible before I removed being obscured was
> >> confusing. A frame could be visible but obscured, which is for me means
> >> it's invisible and can't be seen. That makes no sense to me.
> >
> > But nothing else makes sense on TTY when we have multiple frames on
> > the same display.  So for the purpose of switching frames, the
> > meaning of "visible" on TTY should be tweaked to produce the expected
> > effect.
> 
> This can be done on other-frame and maybe elsewhere in Lisp, as I showed
> in my patch.

What about next-frame with non-nil 2nd argument?

Are you saying that every call to next-frame should be audited and
changed if needed to DTRT with the new definition of "visible" for TTY
frames?  That'd mean an incompatible change, so my proposal is to
avoid that need by changing something on the C level.  Are you against
that as well?  If so, please explain your objections to changing
candidate_frame and/or next-frame/prev-frame as I proposed up-thread.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Wed, 05 Feb 2025 06:28:53 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: rudalics <at> gmx.at,  76031 <at> debbugs.gnu.org
>> Date: Tue, 04 Feb 2025 21:34:20 +0100
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> The semantics of being visible before I removed being obscured was
>> >> confusing. A frame could be visible but obscured, which is for me means
>> >> it's invisible and can't be seen. That makes no sense to me.
>> >
>> > But nothing else makes sense on TTY when we have multiple frames on
>> > the same display.  So for the purpose of switching frames, the
>> > meaning of "visible" on TTY should be tweaked to produce the expected
>> > effect.
>> 
>> This can be done on other-frame and maybe elsewhere in Lisp, as I showed
>> in my patch.
>
> What about next-frame with non-nil 2nd argument?
>
> Are you saying that every call to next-frame should be audited and
> changed if needed to DTRT with the new definition of "visible" for TTY
> frames?  That'd mean an incompatible change, so my proposal is to
> avoid that need by changing something on the C level.  Are you against
> that as well?  If so, please explain your objections to changing
> candidate_frame and/or next-frame/prev-frame as I proposed up-thread.

I'm proposing this change, yes, visible = visible, and not with the
exception that tty root frames that are marked visible are actually
invisible as far as redisplay is concerned.

The reason is the C code. The obscured thing appears to me like a
kludge. Removing it simplifies things and makes it easier to reason
about frames.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Gerd Möllmann
 <gerd.moellmann <at> gmail.com>
Cc: 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Wed, 5 Feb 2025 09:31:18 +0100

> I think there's a conceptual problem here: the meaning of "invisible"
> on TTY is different from its meaning on GUI displays.  On GUI display,
> "invisible" means the frame is not on display at all, whereas on TTY
> the frame is there, it's just obscured by the one(s) above it.  So I
> think we need to change candidate_frame to consider TTY frames
> "visible" for the purpose of returning "visible" frames in next_frame
> and prev_frame.

The concept of frame visibility has so many interpretations within Emcas
that it's virtually impossible to say what it really means.

- Convey to the window manager whether a frame should be displayed or
  not.

- Tell redisplay to draw the frame or not (for the case when Emacs is
  its own window manager as on a tty).

- Tell the buffer display methods whether a frame may be considered for
  displaying the buffer.

- Tell 'other-frame' which frames it should consider.

- Simply allow the user to say that a frame should be visible or not and
  subsequently ask for whether it is.

Note that the last three cannot be controlled for tty frames on Emacs
versions <= 30.  I suppose that nobody did really care because (I still
insist that) multiple frames are rarely used on ttys.  With child
frames, however, the need arises to at least consider child frames as
invisible on ttys because IIUC many packages create a child frame once
only and subsequently toggle its visibility.  I disregard here how these
packages manage users that switch root frames and want to display the
child frame on any of them - IIUC we cannot reparent child frames on
ttys at the moment.

Currently, on master, do_switch_frame in

	      if (old_root != new_root)
		SET_FRAME_VISIBLE (old_root, false);

quite rudely decides that a top tty frame should be no more visible when
switching away from it.  But I'm afraid that changing this alone will
not suffice to obtain a reasonable behavior WRT the issues cited above.

martin

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Wed, 05 Feb 2025 09:58:13 +0100

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

>> I think there's a conceptual problem here: the meaning of "invisible"
>> on TTY is different from its meaning on GUI displays.  On GUI display,
>> "invisible" means the frame is not on display at all, whereas on TTY
>> the frame is there, it's just obscured by the one(s) above it.  So I
>> think we need to change candidate_frame to consider TTY frames
>> "visible" for the purpose of returning "visible" frames in next_frame
>> and prev_frame.
>
> The concept of frame visibility has so many interpretations within Emcas
> that it's virtually impossible to say what it really means.
>
> - Convey to the window manager whether a frame should be displayed or
>   not.
>
> - Tell redisplay to draw the frame or not (for the case when Emacs is
>   its own window manager as on a tty).
>
> - Tell the buffer display methods whether a frame may be considered for
>   displaying the buffer.
>
> - Tell 'other-frame' which frames it should consider.
>
> - Simply allow the user to say that a frame should be visible or not and
>   subsequently ask for whether it is.
>
> Note that the last three cannot be controlled for tty frames on Emacs
> versions <= 30.  I suppose that nobody did really care because (I still
> insist that) multiple frames are rarely used on ttys.

I think the same, and in addition to that tab-bar is much better from a
usability standpoint.

> With child frames, however, the need arises to at least consider child
> frames as invisible on ttys because IIUC many packages create a child
> frame once only and subsequently toggle its visibility.

True.

> I disregard here how these packages manage users that switch root
> frames and want to display the child frame on any of them - IIUC we
> cannot reparent child frames on ttys at the moment.

True. I haven't implemented re-parenting. Could be done of course, but
I'm not volunteering.

>
> Currently, on master, do_switch_frame in
>
> 	      if (old_root != new_root)
> 		SET_FRAME_VISIBLE (old_root, false);
>
> quite rudely decides that a top tty frame should be no more visible when
> switching away from it.  But I'm afraid that changing this alone will
> not suffice to obtain a reasonable behavior WRT the issues cited above.

Maybe, could be.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: rudalics <at> gmx.at, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Wed, 05 Feb 2025 15:23:13 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: rudalics <at> gmx.at,  76031 <at> debbugs.gnu.org
> Date: Tue, 04 Feb 2025 15:30:42 +0100
> 
> +    (cl-flet ((skip (frame)
> +                (or (eq frame sframe)
> +                    (if (display-graphic-p frame)
> +                        (not (frame-visible-p frame))
> +                      (and (frame-parent frame)
> +                           (not (frame-visible-p frame)))))))

Thanks, but I'm worried that we will have to special-case TTY frames
in Lisp, due to these changes.  I think this again indicates that we
use "frame visibility" for several different purposes.  If so, a
better way forward would be to make the frame's visibility flag a
tristate or maybe even more values, instead of a simple boolean.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Wed, 05 Feb 2025 14:43:24 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: rudalics <at> gmx.at,  76031 <at> debbugs.gnu.org
>> Date: Tue, 04 Feb 2025 15:30:42 +0100
>> 
>> +    (cl-flet ((skip (frame)
>> +                (or (eq frame sframe)
>> +                    (if (display-graphic-p frame)
>> +                        (not (frame-visible-p frame))
>> +                      (and (frame-parent frame)
>> +                           (not (frame-visible-p frame)))))))
>
> Thanks, but I'm worried that we will have to special-case TTY frames
> in Lisp, due to these changes.  I think this again indicates that we
> use "frame visibility" for several different purposes.  If so, a
> better way forward would be to make the frame's visibility flag a
> tristate or maybe even more values, instead of a simple boolean.

What would the values of such a visibility enum be?

I find it easier to have a simple definition in C, and let Lisp decide
what it wants to do, basically on a use-case basis. For example, if we
decide other-frame should work with tty root frames that are not
visible, let other-frame do it. Other function might not want to do the
same thing.

An enum, on the other hand, makes things complicated for both C
internals and Lisp.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: rudalics <at> gmx.at, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Wed, 05 Feb 2025 15:57:03 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: rudalics <at> gmx.at,  76031 <at> debbugs.gnu.org
> Date: Wed, 05 Feb 2025 06:28:53 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> >> Cc: rudalics <at> gmx.at,  76031 <at> debbugs.gnu.org
> >> Date: Tue, 04 Feb 2025 21:34:20 +0100
> >> 
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> >> The semantics of being visible before I removed being obscured was
> >> >> confusing. A frame could be visible but obscured, which is for me means
> >> >> it's invisible and can't be seen. That makes no sense to me.
> >> >
> >> > But nothing else makes sense on TTY when we have multiple frames on
> >> > the same display.  So for the purpose of switching frames, the
> >> > meaning of "visible" on TTY should be tweaked to produce the expected
> >> > effect.
> >> 
> >> This can be done on other-frame and maybe elsewhere in Lisp, as I showed
> >> in my patch.
> >
> > What about next-frame with non-nil 2nd argument?
> >
> > Are you saying that every call to next-frame should be audited and
> > changed if needed to DTRT with the new definition of "visible" for TTY
> > frames?  That'd mean an incompatible change, so my proposal is to
> > avoid that need by changing something on the C level.  Are you against
> > that as well?  If so, please explain your objections to changing
> > candidate_frame and/or next-frame/prev-frame as I proposed up-thread.
> 
> I'm proposing this change, yes, visible = visible, and not with the
> exception that tty root frames that are marked visible are actually
> invisible as far as redisplay is concerned.
> 
> The reason is the C code. The obscured thing appears to me like a
> kludge. Removing it simplifies things and makes it easier to reason
> about frames.

I understand that the problem was with the terminology: saying that a
frame was "visible" when in fact it was completely obscured.

If this is a terminology problem, maybe we can solve it by changing
the terminology.  E.g., we could have two flags instead of one:

  . displayed_p flag -- if the frame is on display
  . obscured_p flag -- if the frame is obscured by another frame

TTY frames then could be "obscured", but will always be "displayed".
GUI frames could be either "obscured", "displayed" or not "displayed".

Then we can modify next-frame and other-frame to DTRT using these two
flags.

WDYT?

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Wed, 05 Feb 2025 15:21:50 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: rudalics <at> gmx.at,  76031 <at> debbugs.gnu.org
>> Date: Wed, 05 Feb 2025 06:28:53 +0100
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> >> Cc: rudalics <at> gmx.at,  76031 <at> debbugs.gnu.org
>> >> Date: Tue, 04 Feb 2025 21:34:20 +0100
>> >> 
>> >> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >> 
>> >> >> The semantics of being visible before I removed being obscured was
>> >> >> confusing. A frame could be visible but obscured, which is for me means
>> >> >> it's invisible and can't be seen. That makes no sense to me.
>> >> >
>> >> > But nothing else makes sense on TTY when we have multiple frames on
>> >> > the same display.  So for the purpose of switching frames, the
>> >> > meaning of "visible" on TTY should be tweaked to produce the expected
>> >> > effect.
>> >> 
>> >> This can be done on other-frame and maybe elsewhere in Lisp, as I showed
>> >> in my patch.
>> >
>> > What about next-frame with non-nil 2nd argument?
>> >
>> > Are you saying that every call to next-frame should be audited and
>> > changed if needed to DTRT with the new definition of "visible" for TTY
>> > frames?  That'd mean an incompatible change, so my proposal is to
>> > avoid that need by changing something on the C level.  Are you against
>> > that as well?  If so, please explain your objections to changing
>> > candidate_frame and/or next-frame/prev-frame as I proposed up-thread.
>> 
>> I'm proposing this change, yes, visible = visible, and not with the
>> exception that tty root frames that are marked visible are actually
>> invisible as far as redisplay is concerned.
>> 
>> The reason is the C code. The obscured thing appears to me like a
>> kludge. Removing it simplifies things and makes it easier to reason
>> about frames.
>
> I understand that the problem was with the terminology: saying that a
> frame was "visible" when in fact it was completely obscured.
>
> If this is a terminology problem, maybe we can solve it by changing
> the terminology.  E.g., we could have two flags instead of one:
>
>   . displayed_p flag -- if the frame is on display
>   . obscured_p flag -- if the frame is obscured by another frame
>
> TTY frames then could be "obscured", but will always be "displayed".
> GUI frames could be either "obscured", "displayed" or not "displayed".
>
> Then we can modify next-frame and other-frame to DTRT using these two
> flags.
>
> WDYT?

I don't find that a good idea because

- the former obscured flag is equal to (and (not visible) (is root)
  (is tty frame)). No need for a flag.

- a new obscured that really means a frame is obscured by another frame
  or something cannot be computed easily, except for root frames.

- an obscured flag doesn't really help with the different use-cases.
  AFAIK it wasn't even exposed to Lisp.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: gerd.moellmann <at> gmail.com, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Wed, 05 Feb 2025 16:24:43 +0200

> Date: Wed, 5 Feb 2025 09:31:18 +0100
> Cc: 76031 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > I think there's a conceptual problem here: the meaning of "invisible"
>  > on TTY is different from its meaning on GUI displays.  On GUI display,
>  > "invisible" means the frame is not on display at all, whereas on TTY
>  > the frame is there, it's just obscured by the one(s) above it.  So I
>  > think we need to change candidate_frame to consider TTY frames
>  > "visible" for the purpose of returning "visible" frames in next_frame
>  > and prev_frame.
> 
> The concept of frame visibility has so many interpretations within Emcas
> that it's virtually impossible to say what it really means.
> 
> - Convey to the window manager whether a frame should be displayed or
>    not.

This is the "displayed"/non-"displayed" state.

> - Tell redisplay to draw the frame or not (for the case when Emacs is
>    its own window manager as on a tty).

This is the "obscured"/not "obscured" state.

> - Tell the buffer display methods whether a frame may be considered for
>    displaying the buffer.

This is "displayed".

> - Tell 'other-frame' which frames it should consider.

Likewise.

> - Simply allow the user to say that a frame should be visible or not and
>    subsequently ask for whether it is.

This is "displayed", AFAIU.

So I think we can introduce two flags, splitting the existing
"visible" flag between them.  Then we can modify the relevant C
functions to handle each flag accordingly, so that other-frame and
next-frame behave sensibly with both GUI and TTY frames.

Does it make sense?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: rudalics <at> gmx.at, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Wed, 05 Feb 2025 16:38:14 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: rudalics <at> gmx.at,  76031 <at> debbugs.gnu.org
> Date: Wed, 05 Feb 2025 14:43:24 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Thanks, but I'm worried that we will have to special-case TTY frames
> > in Lisp, due to these changes.  I think this again indicates that we
> > use "frame visibility" for several different purposes.  If so, a
> > better way forward would be to make the frame's visibility flag a
> > tristate or maybe even more values, instead of a simple boolean.
> 
> What would the values of such a visibility enum be?

I proposed one possible way in my other messages earlier today.  Other
factoring is, of course, possible.

> I find it easier to have a simple definition in C, and let Lisp decide
> what it wants to do, basically on a use-case basis. For example, if we
> decide other-frame should work with tty root frames that are not
> visible, let other-frame do it. Other function might not want to do the
> same thing.
> 
> An enum, on the other hand, makes things complicated for both C
> internals and Lisp.

We could have two separate flags or a bitmap in C.  For Lisp, I
propose to use predicates and/or teach the likes of next-frame to deal
with these flags internally, in some way that is convenient for Lisp
programs.  Something similar to the possible values of the 2nd
argument of next-frame.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: rudalics <at> gmx.at, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Wed, 05 Feb 2025 16:41:53 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: rudalics <at> gmx.at,  76031 <at> debbugs.gnu.org
> Date: Wed, 05 Feb 2025 15:21:50 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> >> Cc: rudalics <at> gmx.at,  76031 <at> debbugs.gnu.org
> >> Date: Wed, 05 Feb 2025 06:28:53 +0100
> >> 
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> >> >> Cc: rudalics <at> gmx.at,  76031 <at> debbugs.gnu.org
> >> >> Date: Tue, 04 Feb 2025 21:34:20 +0100
> >> >> 
> >> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> >> 
> >> >> >> The semantics of being visible before I removed being obscured was
> >> >> >> confusing. A frame could be visible but obscured, which is for me means
> >> >> >> it's invisible and can't be seen. That makes no sense to me.
> >> >> >
> >> >> > But nothing else makes sense on TTY when we have multiple frames on
> >> >> > the same display.  So for the purpose of switching frames, the
> >> >> > meaning of "visible" on TTY should be tweaked to produce the expected
> >> >> > effect.
> >> >> 
> >> >> This can be done on other-frame and maybe elsewhere in Lisp, as I showed
> >> >> in my patch.
> >> >
> >> > What about next-frame with non-nil 2nd argument?
> >> >
> >> > Are you saying that every call to next-frame should be audited and
> >> > changed if needed to DTRT with the new definition of "visible" for TTY
> >> > frames?  That'd mean an incompatible change, so my proposal is to
> >> > avoid that need by changing something on the C level.  Are you against
> >> > that as well?  If so, please explain your objections to changing
> >> > candidate_frame and/or next-frame/prev-frame as I proposed up-thread.
> >> 
> >> I'm proposing this change, yes, visible = visible, and not with the
> >> exception that tty root frames that are marked visible are actually
> >> invisible as far as redisplay is concerned.
> >> 
> >> The reason is the C code. The obscured thing appears to me like a
> >> kludge. Removing it simplifies things and makes it easier to reason
> >> about frames.
> >
> > I understand that the problem was with the terminology: saying that a
> > frame was "visible" when in fact it was completely obscured.
> >
> > If this is a terminology problem, maybe we can solve it by changing
> > the terminology.  E.g., we could have two flags instead of one:
> >
> >   . displayed_p flag -- if the frame is on display
> >   . obscured_p flag -- if the frame is obscured by another frame
> >
> > TTY frames then could be "obscured", but will always be "displayed".
> > GUI frames could be either "obscured", "displayed" or not "displayed".
> >
> > Then we can modify next-frame and other-frame to DTRT using these two
> > flags.
> >
> > WDYT?
> 
> I don't find that a good idea because

Not even in principle, i.e. to have two flags instead of one?  The
details of the flags could be different from what I proposed.

Do you disagree that we have several different meanings of "invisible
frame", and that it would be better not to conflate them into a single
boolean?

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Wed, 05 Feb 2025 16:05:26 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> I don't find that a good idea because
>
> Not even in principle, i.e. to have two flags instead of one?  The
> details of the flags could be different from what I proposed.

Not even in principle, no. I don't see ATM how that would be useful.

> Do you disagree that we have several different meanings of "invisible
> frame", and that it would be better not to conflate them into a single
> boolean?

As I see it, the different meanings of "visible" are actually just the
different effect of being visible in different use-cases.

For example, my guess is that the old "if a tty frame is not displayed
on the terminal (= "obscured") then consider it visible nonetheless" was
just to make use cases like other-frame work.

I propose something simpler: Make visible = not displayed, and move the
different effects on use-cases to the use-cases themselves.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: rudalics <at> gmx.at, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Wed, 05 Feb 2025 17:27:40 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: rudalics <at> gmx.at,  76031 <at> debbugs.gnu.org
> Date: Wed, 05 Feb 2025 16:05:26 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> I don't find that a good idea because
> >
> > Not even in principle, i.e. to have two flags instead of one?  The
> > details of the flags could be different from what I proposed.
> 
> Not even in principle, no. I don't see ATM how that would be useful.

It could be useful if it will solve the problems with next-frame and
other-frame without requiring modifications of Lisp code that is too
high-level.

We could also keep using a single flag, just call it by a different
name, so that it won't confuse due to the fact that "not visible"
could be caused either by not displaying a frame or by its being
obscured.  next-frame and friends care about the former, but not about
the latter.

> > Do you disagree that we have several different meanings of "invisible
> > frame", and that it would be better not to conflate them into a single
> > boolean?
> 
> As I see it, the different meanings of "visible" are actually just the
> different effect of being visible in different use-cases.
> 
> For example, my guess is that the old "if a tty frame is not displayed
> on the terminal (= "obscured") then consider it visible nonetheless" was
> just to make use cases like other-frame work.

Maybe so, but other-frame and other similar functions do have to work
reasonably with TTY frames, right?

Also, why aren't you annoyed by the fact that a GUI frame obscured by
another GUI frame is not considered "invisible"?  Isn't that the same
situation as with 2 TTY frames on the same display?

> I propose something simpler: Make visible = not displayed, and move the
> different effects on use-cases to the use-cases themselves.

By "the use-cases", do you mean modifications of the Lisp code which
calls next-frame etc.?  That would mean changes all over the place,
and not just in Emacs core.  I fear that the 3 functions we found are
just the tip of a very large iceberg.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Wed, 05 Feb 2025 18:13:30 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.mo>> As I see it, the different meanings of "visible" are actually just the
>> different effect of being visible in different use-cases.
>>
>> For example, my guess is that the old "if a tty frame is not displayed
>> on the terminal (= "obscured") then consider it visible nonetheless" was
>> just to make use cases like other-frame work.
>
> Maybe so, but other-frame and other similar functions do have to work
> reasonably with TTY frames, right?

I sent a patch for other-frame.

> Also, why aren't you annoyed by the fact that a GUI frame obscured by
> another GUI frame is not considered "invisible"?  Isn't that the same
> situation as with 2 TTY frames on the same display?

If a GUI frame is visible, it must be drawn. If a GUI frame is
invisible, it must not be drawn to.

Details depend on the window system, expose events, possibly the window
manager. Clipping is not Emacs' responsibility. Insofar why would I be
annoyed? It's just how things work.

Before child frames: TTY frames are always visible, invisible doesn't
exist. Visible frames _must_not_ always be drawn, with the known
exception.

After child frames: If a TTY frame is visible, it must be drawn. If a
TTY frame is invisible, it must not be drawn to.

If that's not better, I don't know.

>> I propose something simpler: Make visible = not displayed, and move the
>> different effects on use-cases to the use-cases themselves.
>
> By "the use-cases", do you mean modifications of the Lisp code which
> calls next-frame etc.?  That would mean changes all over the place,
> and not just in Emacs core.  I fear that the 3 functions we found are
> just the tip of a very large iceberg.

I mean use-cases like other-frame, and I'm not afraid :-). If it's Lisp,
it's easy to change.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Cc: 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Wed, 5 Feb 2025 20:20:18 +0100

> After child frames: If a TTY frame is visible, it must be drawn. If a
> TTY frame is invisible, it must not be drawn to.

The proof of the pudding is in the eating.  And I'm afraid that we will
get our bug reports sooner or later.  Anyway, try the following: Make a
child frame on the selected frame like

(setq frame
      (make-frame
       `((parent-frame . ,(selected-frame))
	 (left . 40) (top . 10)
	 (width . 20) (height . 10))))

do C-x 5 2 and evaluate (visible-frame-list).  The child frame will be
listed although it is not drawn.

Or do either

(setq frame (make-frame))
(make-frame-visible frame)

or

(setq frame (make-frame))
(select-frame frame)
(make-frame-invisible frame)

In both cases C-x 5 o will get you out but before that you can't type
anything into the window.  Frame visibility is a very fragile concept.

martin

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Wed, 05 Feb 2025 21:24:37 +0100

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

>> After child frames: If a TTY frame is visible, it must be drawn. If a
>> TTY frame is invisible, it must not be drawn to.
>
> The proof of the pudding is in the eating.  And I'm afraid that we will
> get our bug reports sooner or later.  Anyway, try the following: Make a
> child frame on the selected frame like
>
> (setq frame
>       (make-frame
>        `((parent-frame . ,(selected-frame))
> 	 (left . 40) (top . 10)
> 	 (width . 20) (height . 10))))
>
> do C-x 5 2 and evaluate (visible-frame-list).  The child frame will be
> listed although it is not drawn.

Yes, but that's not related to the visibility of the root frame. It's
part of the semantics that need to be defined for tty child frame if one
really wants to go all the way to general child frames,

> Or do either
>
> (setq frame (make-frame))
> (make-frame-visible frame)
>
> or
>
> (setq frame (make-frame))
> (select-frame frame)
> (make-frame-invisible frame)
>
> In both cases C-x 5 o will get you out but before that you can't type
> anything into the window.  Frame visibility is a very fragile concept.

Yes, it's some way to go, for sure.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Thu, 06 Feb 2025 08:33:41 +0100

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> martin rudalics <rudalics <at> gmx.at> writes:
>
>>> After child frames: If a TTY frame is visible, it must be drawn. If a
>>> TTY frame is invisible, it must not be drawn to.
>>
>> The proof of the pudding is in the eating.  And I'm afraid that we will
>> get our bug reports sooner or later.  Anyway, try the following: Make a
>> child frame on the selected frame like
>>
>> (setq frame
>>       (make-frame
>>        `((parent-frame . ,(selected-frame))
>> 	 (left . 40) (top . 10)
>> 	 (width . 20) (height . 10))))
>>
>> do C-x 5 2 and evaluate (visible-frame-list).  The child frame will be
>> listed although it is not drawn.
>
> Yes, but that's not related to the visibility of the root frame. It's
> part of the semantics that need to be defined for tty child frame if one
> really wants to go all the way to general child frames,

FWIW, I tried that with a GUI Emacs here.

  (setq r1 (selected-frame))
  (setq r2 (make-frame))
  (setq c (make-frame `((parent-frame . ,r2))))
  (make-frame-invisible R2)

Now R2 and C are no longer displayed, but

  (frame-visible-p c)
  => t

  (select-frame-set-input-focus c)
  => doesn't return a value??
  (eq r1 (selected-frame))
  => t


  

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

From: martin rudalics <rudalics <at> gmx.at>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Thu, 6 Feb 2025 10:39:11 +0100

> FWIW, I tried that with a GUI Emacs here.
>
>    (setq r1 (selected-frame))
>    (setq r2 (make-frame))
>    (setq c (make-frame `((parent-frame . ,r2))))
>    (make-frame-invisible R2)
>
> Now R2 and C are no longer displayed, but
>
>    (frame-visible-p c)
>    => t

Hopefully.  You did not make C invisible.  On GUIs visibility does not
necessarily mean that the frame appears on display and vice versa.

We could make a child frame invisible whenever we make its parent
invisible.  But when we then make the parent visible again, how would we
specify the child frame's visibility?  And what would we do when the
child frame gets reparented?  On GUIs the visibility flag exactly
reflects the user's demand, no more and no less.  On ttys it never did
and still doesn't.

>    (select-frame-set-input-focus c)
>    => doesn't return a value??

It returns t but probably the minibuffer window is on the invisible
frame.

>    (eq r1 (selected-frame))
>    => t

Hopefully.  Note that the entire management of visibility and input
focus is in the hands of the WM.  The WM decides whether a new frame
made via C-x 5 2 gets raised, input focus and so on.  And it decides
which frame to select when a frame is deleted, made invisible or
visible.

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Fri, 7 Feb 2025 21:31:00 +0100

> Yes, it's some way to go, for sure.

I think I found a recipe to handle most of the problems we encountered
so far.  But before you would have to solve the following problem:

With emacs -Q -nw evaluate

(make-frame
 `((parent-frame . ,(selected-frame))
   (left . 40) (top . 10)
   (width . 20) (height . 10)))

and then do C-x 5 2 followed by C-x 5 o.  The child frame is not redrawn
here.

martin

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Sat, 08 Feb 2025 05:27:01 +0100

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

>> Yes, it's some way to go, for sure.
>
> I think I found a recipe to handle most of the problems we encountered
> so far.  

Sounds great1

> But before you would have to solve the following problem:

Sounds not so great :-).

> With emacs -Q -nw evaluate
>
> (make-frame
>  `((parent-frame . ,(selected-frame))
>    (left . 40) (top . 10)
>    (width . 20) (height . 10)))
>
> and then do C-x 5 2 followed by C-x 5 o.  The child frame is not redrawn
> here.

I assume that is with the patch I sent for other-frame, because
otherwise C-x 5 o wouldn't work?

What I see with the patch is that the border of the child frame seems to
be partially "damaged", so to speak. Is it that, or do you mean
something else?

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

From: martin rudalics <rudalics <at> gmx.at>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Sat, 8 Feb 2025 09:09:54 +0100

[Message part 1 (text/plain, inline)]

>> With emacs -Q -nw evaluate
>>
>> (make-frame
>>   `((parent-frame . ,(selected-frame))
>>     (left . 40) (top . 10)
>>     (width . 20) (height . 10)))
>>
>> and then do C-x 5 2 followed by C-x 5 o.  The child frame is not redrawn
>> here.
>
> I assume that is with the patch I sent for other-frame, because
> otherwise C-x 5 o wouldn't work?

It works on unpatched master because the child frame made above is
considered visible and thus a valid target for C-x 5 o

(setq child
      (make-frame
       `((parent-frame . ,(selected-frame))
	 (left . 40) (top . 10)
	 (width . 20) (height . 10))))

C-x 5 2

(frame-visible-p child)

> What I see with the patch is that the border of the child frame seems to
> be partially "damaged", so to speak. Is it that, or do you mean
> something else?

I attach a screenshot for the record.  Meanwhile it seems that I fixed
this here by marking all the child frame's ancestors including its root
as garbaged and visible in do_switch_frame.  So don't bother for the
moment.

martin

[child frame after C-x 5 o.png (image/png, attachment)]

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Martin Rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Sat, 8 Feb 2025 10:33:44 +0100

[Message part 1 (text/plain, inline)]

> On 8. Feb 2025, at 09:09, martin rudalics <rudalics <at> gmx.at> wrote:
> 
> I attach a screenshot for the record.  Meanwhile it seems that I fixed
> this here by marking all the child frame's ancestors including its root
> as garbaged and visible in do_switch_frame.  So don't bother for the
> moment.

Ah, okay, thanks!

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Sun, 9 Feb 2025 11:08:50 +0100

[Message part 1 (text/plain, inline)]

Attach find a patch that should fix the following scenarios posted in
this thread (all with emas -Q -nw):

>   C-x 5 f src/xdisp.c RET
>   C-x 5 o
>
> The last step should have switched back to frame F1 showing the
> *scratch* buffer, but instead it does nothing, showing the frame F2 as
> before.
>
> Perhaps related, "M-x select-frame-by-name" insists that the only
> frame to switch to is the currently selected frame F2; if you try to
> type "F1" at the prompt, you get "No match".

These work here now as intended.

> (setq frame (make-frame))
> (make-frame-visible frame)

and

> (setq frame (make-frame))
> (select-frame frame)
> (make-frame-invisible frame)

No strange effects observed any more.

> (make-frame
>  `((parent-frame . ,(selected-frame))
>    (left . 40) (top . 10)
>    (width . 20) (height . 10)))
>
> and then do C-x 5 2 followed by C-x 5 o.  The child frame is not redrawn
> here.

The child frame gets redrawn and selected (the latter was the hardest
part).

martin

[frame_redisplay_p.diff (text/x-patch, attachment)]

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Sun, 09 Feb 2025 11:36:45 +0100

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

> Attach find a patch that should fix the following scenarios posted in
> this thread (all with emas -Q -nw):
>
>>   C-x 5 f src/xdisp.c RET
>>   C-x 5 o
>>
>> The last step should have switched back to frame F1 showing the
>> *scratch* buffer, but instead it does nothing, showing the frame F2 as
>> before.
>>
>> Perhaps related, "M-x select-frame-by-name" insists that the only
>> frame to switch to is the currently selected frame F2; if you try to
>> type "F1" at the prompt, you get "No match".
>
> These work here now as intended.
>
>> (setq frame (make-frame))
>> (make-frame-visible frame)
>
> and
>
>> (setq frame (make-frame))
>> (select-frame frame)
>> (make-frame-invisible frame)
>
> No strange effects observed any more.
>
>> (make-frame
>>  `((parent-frame . ,(selected-frame))
>>    (left . 40) (top . 10)
>>    (width . 20) (height . 10)))
>>
>> and then do C-x 5 2 followed by C-x 5 o.  The child frame is not redrawn
>> here.
>
> The child frame gets redrawn and selected (the latter was the hardest
> part).

Nice, congrats!

I found one minor problem here, using your previous setup that opens
child frames with C-l and M-l.

- emacs -Q -nw
- C-l
- M-l
- C-x 5 2 (-> new root frame, everything is fine)
- M-x switch-frame-by-name RET F2 RET

=> I think I'm back to the first root frame, not sure, maybe not, but
the child frames are not redrawn. It seems that F2 is the selected
frame. Something is weird when entering text here. Looks like C-x 5 o
fixes that eventually, or even immediately.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Sun, 9 Feb 2025 12:08:51 +0100

> I found one minor problem here, using your previous setup that opens
> child frames with C-l and M-l.
>
> - emacs -Q -nw
> - C-l
> - M-l
> - C-x 5 2 (-> new root frame, everything is fine)
> - M-x switch-frame-by-name RET F2 RET
>
> => I think I'm back to the first root frame, not sure, maybe not, but
> the child frames are not redrawn. It seems that F2 is the selected
> frame. Something is weird when entering text here. Looks like C-x 5 o
> fixes that eventually, or even immediately.

It works here as expected with a gtk build but I see what you describe
when I build --without-x.  So this looks like a maladjusted #if.  I'll
look into it.  Does it happen when you build with X or whatever you use
instead?

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Sun, 9 Feb 2025 12:19:39 +0100

[Message part 1 (text/plain, inline)]

> It works here as expected with a gtk build but I see what you describe
> when I build --without-x.  So this looks like a maladjusted #if.

That was the cause IIUC.

> I'll
> look into it.  Does it happen when you build with X or whatever you use
> instead?

New patch attached.

martin

[frame_redisplay_p.diff (text/x-patch, attachment)]

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Sun, 09 Feb 2025 12:20:55 +0100

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

>> I found one minor problem here, using your previous setup that opens
>> child frames with C-l and M-l.
>>
>> - emacs -Q -nw
>> - C-l
>> - M-l
>> - C-x 5 2 (-> new root frame, everything is fine)
>> - M-x switch-frame-by-name RET F2 RET
>>
>> => I think I'm back to the first root frame, not sure, maybe not, but
>> the child frames are not redrawn. It seems that F2 is the selected
>> frame. Something is weird when entering text here. Looks like C-x 5 o
>> fixes that eventually, or even immediately.
>
> It works here as expected with a gtk build but I see what you describe
> when I build --without-x.  So this looks like a maladjusted #if.  I'll
> look into it.  Does it happen when you build with X or whatever you use
> instead?

Yes, it's the same here both built --with-ns and --without-ns.
That's HAVE_WINDOW_SYSTEM and HAVE_NS.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Sun, 09 Feb 2025 12:26:43 +0100

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

>> New patch attached.

Works perfectly!

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

From: martin rudalics <rudalics <at> gmx.at>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Mon, 10 Feb 2025 11:15:02 +0100

> Works perfectly!

Pushed now.  Even if it has remaining bugs, I'd rather have feedback
right away wrt whether it violates some long-standing practice.

I have not fixed the documentation yet and maybe I'll update the
semantics of visibility later in the sense that FRAME_VISIBLE_P won't
return true when a child frame has its visible slot true but one of its
ancestors doesn't.  For tty _and_ GUI child frames!

martin

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Martin Rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Mon, 10 Feb 2025 16:22:08 +0100

> On 10. Feb 2025, at 11:15, martin rudalics <rudalics <at> gmx.at> wrote:
> 
> > Works perfectly!
> 
> Pushed now.  Even if it has remaining bugs, I'd rather have feedback
> right away wrt whether it violates some long-standing practice.
> 
> I have not fixed the documentation yet and maybe I'll update the
> semantics of visibility later in the sense that FRAME_VISIBLE_P won't
> return true when a child frame has its visible slot true but one of its
> ancestors doesn't.  For tty _and_ GUI child frames

Thanks! 

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: gerd.moellmann <at> gmail.com, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Thu, 13 Feb 2025 12:43:35 +0200

> Date: Mon, 10 Feb 2025 11:15:02 +0100
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 76031 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > Works perfectly!
> 
> Pushed now.  Even if it has remaining bugs, I'd rather have feedback
> right away wrt whether it violates some long-standing practice.

My original recipes now work, so I'm closing this bug.

> I have not fixed the documentation yet and maybe I'll update the
> semantics of visibility later in the sense that FRAME_VISIBLE_P won't
> return true when a child frame has its visible slot true but one of its
> ancestors doesn't.  For tty _and_ GUI child frames!

Yes, we should update the documentation on these aspects of frame
visibility.  I admit I'm still rather confused about what it means to
be "invisible" for a GUI frame, for a TTY frame, and for a child frame
in both cases.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: 76031-done <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Thu, 13 Feb 2025 12:44:28 +0200

Closing.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 76031 <at> debbugs.gnu.org
Subject: Re: bug#76031: 31.0.50; Switching frames on TTY display doesn't work
Date: Thu, 13 Feb 2025 11:59:52 +0100

> Yes, we should update the documentation on these aspects of frame
> visibility.  I admit I'm still rather confused about what it means to
> be "invisible" for a GUI frame, for a TTY frame, and for a child frame
> in both cases.

I'm working on it.

martin

Previous Next

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