* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
@ 2025-02-03 17:23 Eli Zaretskii
2025-02-03 19:20 ` Gerd Möllmann
0 siblings, 1 reply; 38+ messages in thread
From: Eli Zaretskii @ 2025-02-03 17:23 UTC (permalink / raw)
To: 76031; +Cc: martin rudalics, Gerd Möllmann
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))
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-03 17:23 bug#76031: 31.0.50; Switching frames on TTY display doesn't work Eli Zaretskii
@ 2025-02-03 19:20 ` Gerd Möllmann
2025-02-03 20:05 ` Eli Zaretskii
2025-02-04 8:09 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 38+ messages in thread
From: Gerd Möllmann @ 2025-02-03 19:20 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: martin rudalics, 76031
Eli Zaretskii <eliz@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?
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-03 19:20 ` Gerd Möllmann
@ 2025-02-03 20:05 ` Eli Zaretskii
2025-02-04 8:09 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 38+ messages in thread
From: Eli Zaretskii @ 2025-02-03 20:05 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: rudalics, 76031
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: 76031@debbugs.gnu.org, martin rudalics <rudalics@gmx.at>
> Date: Mon, 03 Feb 2025 20:20:51 +0100
>
> Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-03 19:20 ` Gerd Möllmann
2025-02-03 20:05 ` Eli Zaretskii
@ 2025-02-04 8:09 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-04 8:46 ` Gerd Möllmann
2025-02-04 14:25 ` Eli Zaretskii
1 sibling, 2 replies; 38+ messages in thread
From: martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-04 8:09 UTC (permalink / raw)
To: Gerd Möllmann, Eli Zaretskii; +Cc: 76031
> 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
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-04 8:09 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-04 8:46 ` Gerd Möllmann
2025-02-04 14:26 ` Eli Zaretskii
2025-02-04 14:25 ` Eli Zaretskii
1 sibling, 1 reply; 38+ messages in thread
From: Gerd Möllmann @ 2025-02-04 8:46 UTC (permalink / raw)
To: martin rudalics; +Cc: Eli Zaretskii, 76031
[-- Attachment #1: Type: text/plain, Size: 678 bytes --]
martin rudalics <rudalics@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:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-min-width-display-spec-handling-bug-76014.patch --]
[-- Type: text/x-patch, Size: 2026 bytes --]
From 711f21b659633fb05b81f43f3e81391e5988fe3a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gerd=20M=C3=B6llmann?= <gerd@gnu.org>
Date: Tue, 4 Feb 2025 06:09:52 +0100
Subject: [PATCH] Fix min-width display spec handling (bug#76014)
* src/xdisp.c (display_min_width): Take into account that the output may
already be longer than the specified min-width.
---
src/xdisp.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/xdisp.c b/src/xdisp.c
index ed4a5564427..72311362035 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -5650,7 +5650,7 @@ get_display_property (ptrdiff_t charpos, Lisp_Object prop, Lisp_Object object)
/* Handle 'display' property '(min-width (WIDTH))' at CHARPOS in OBJECT.
OBJECT can be a buffer (or nil, which means the current buffer) or a
- string. MIN_WIDTH is the value of min-width spec that we expect to
+ string. WIDTH_SPEC is the value of min-width spec that we expect to
process. */
static void
display_min_width (struct it *it, ptrdiff_t charpos,
@@ -5696,8 +5696,9 @@ display_min_width (struct it *it, ptrdiff_t charpos,
a stretch that ends beyond the visible portion of the
window if we are truncating screen lines. If we are
requested to do that, some Lisp program went awry. */
- if (!(it->line_wrap == TRUNCATE
- && it->current_x + width > it->last_visible_x))
+ if (width > 0
+ && !(it->line_wrap == TRUNCATE
+ && it->current_x + width > it->last_visible_x))
w = list1 (make_int (width));
}
else
@@ -5708,8 +5709,9 @@ display_min_width (struct it *it, ptrdiff_t charpos,
NULL, true, NULL);
width -= (it->current_x - it->min_width_start) /
FRAME_COLUMN_WIDTH (it->f);
- if (!(it->line_wrap == TRUNCATE
- && it->current_x + width > it->last_visible_x))
+ if (width > 0
+ && !(it->line_wrap == TRUNCATE
+ && it->current_x + width > it->last_visible_x))
w = make_int (width);
}
--
2.48.1
^ permalink raw reply related [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-04 8:09 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-04 8:46 ` Gerd Möllmann
@ 2025-02-04 14:25 ` Eli Zaretskii
2025-02-04 14:49 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 38+ messages in thread
From: Eli Zaretskii @ 2025-02-04 14:25 UTC (permalink / raw)
To: martin rudalics; +Cc: gerd.moellmann, 76031
> Date: Tue, 4 Feb 2025 09:09:48 +0100
> Cc: 76031@debbugs.gnu.org
> From: martin rudalics <rudalics@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?
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-04 8:46 ` Gerd Möllmann
@ 2025-02-04 14:26 ` Eli Zaretskii
2025-02-04 14:30 ` Gerd Möllmann
0 siblings, 1 reply; 38+ messages in thread
From: Eli Zaretskii @ 2025-02-04 14:26 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: rudalics, 76031
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 76031@debbugs.gnu.org
> Date: Tue, 04 Feb 2025 09:46:32 +0100
>
> martin rudalics <rudalics@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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-04 14:26 ` Eli Zaretskii
@ 2025-02-04 14:30 ` Gerd Möllmann
2025-02-04 15:06 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-05 13:23 ` Eli Zaretskii
0 siblings, 2 replies; 38+ messages in thread
From: Gerd Möllmann @ 2025-02-04 14:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rudalics, 76031
[-- Attachment #1: Type: text/plain, Size: 139 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
> Ehm.. wrong patch? You attached the patch for the min-width thingy.
Sorry, here's the right one
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Don-t-skip-tty-root-frames-in-other-frame-bug-76031.patch --]
[-- Type: text/x-patch, Size: 1957 bytes --]
From e042482fe4ec6cfae954cdb3795aeaf14bd09221 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gerd=20M=C3=B6llmann?= <gerd@gnu.org>
Date: Tue, 4 Feb 2025 09:43:18 +0100
Subject: [PATCH] Don't skip tty root frames in other-frame (bug#76031)
* lisp/frame.el (other-frame): Don't skip tty root frames, they are
invisible but can be switched to.
---
lisp/frame.el | 30 +++++++++++++++++-------------
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/lisp/frame.el b/lisp/frame.el
index a55fcb41ce1..0df62ca872b 100644
--- a/lisp/frame.el
+++ b/lisp/frame.el
@@ -1162,19 +1162,23 @@ other-frame
(interactive "p")
(let ((sframe (selected-frame))
(frame (selected-frame)))
- (while (> arg 0)
- (setq frame (next-frame frame))
- (while (and (not (eq frame sframe))
- (not (eq (frame-visible-p frame) t)))
- (setq frame (next-frame frame)))
- (setq arg (1- arg)))
- (while (< arg 0)
- (setq frame (previous-frame frame))
- (while (and (not (eq frame sframe))
- (not (eq (frame-visible-p frame) t)))
- (setq frame (previous-frame frame)))
- (setq arg (1+ arg)))
- (select-frame-set-input-focus frame)))
+ (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)))))))
+ (while (> arg 0)
+ (setq frame (next-frame frame))
+ (while (skip frame)
+ (setq frame (next-frame frame)))
+ (setq arg (1- arg)))
+ (while (< arg 0)
+ (setq frame (previous-frame frame))
+ (while (skip frame)
+ (setq frame (previous-frame frame)))
+ (setq arg (1+ arg)))
+ (select-frame-set-input-focus frame))))
(defun other-frame-prefix ()
"Display the buffer of the next command in a new frame.
--
2.48.1
^ permalink raw reply related [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-04 14:25 ` Eli Zaretskii
@ 2025-02-04 14:49 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 38+ messages in thread
From: martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-04 14:49 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gerd.moellmann, 76031
>> > 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
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-04 14:30 ` Gerd Möllmann
@ 2025-02-04 15:06 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-04 16:19 ` Eli Zaretskii
2025-02-04 18:31 ` Gerd Möllmann
2025-02-05 13:23 ` Eli Zaretskii
1 sibling, 2 replies; 38+ messages in thread
From: martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-04 15:06 UTC (permalink / raw)
To: Gerd Möllmann, Eli Zaretskii; +Cc: 76031
> 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
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-04 15:06 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-04 16:19 ` Eli Zaretskii
2025-02-04 17:54 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-04 18:31 ` Gerd Möllmann
1 sibling, 1 reply; 38+ messages in thread
From: Eli Zaretskii @ 2025-02-04 16:19 UTC (permalink / raw)
To: martin rudalics; +Cc: gerd.moellmann, 76031
> Date: Tue, 4 Feb 2025 16:06:10 +0100
> Cc: 76031@debbugs.gnu.org
> From: martin rudalics <rudalics@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?
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-04 16:19 ` Eli Zaretskii
@ 2025-02-04 17:54 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-04 18:27 ` Gerd Möllmann
0 siblings, 1 reply; 38+ messages in thread
From: martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-04 17:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gerd.moellmann, 76031
> 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
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-04 17:54 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-04 18:27 ` Gerd Möllmann
2025-02-04 20:10 ` Eli Zaretskii
0 siblings, 1 reply; 38+ messages in thread
From: Gerd Möllmann @ 2025-02-04 18:27 UTC (permalink / raw)
To: martin rudalics; +Cc: Eli Zaretskii, 76031
martin rudalics <rudalics@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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-04 15:06 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-04 16:19 ` Eli Zaretskii
@ 2025-02-04 18:31 ` Gerd Möllmann
2025-02-04 20:13 ` Eli Zaretskii
1 sibling, 1 reply; 38+ messages in thread
From: Gerd Möllmann @ 2025-02-04 18:31 UTC (permalink / raw)
To: martin rudalics; +Cc: Eli Zaretskii, 76031
martin rudalics <rudalics@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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-04 18:27 ` Gerd Möllmann
@ 2025-02-04 20:10 ` Eli Zaretskii
2025-02-04 20:22 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 38+ messages in thread
From: Eli Zaretskii @ 2025-02-04 20:10 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: rudalics, 76031
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 76031@debbugs.gnu.org
> Date: Tue, 04 Feb 2025 19:27:40 +0100
>
> martin rudalics <rudalics@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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-04 18:31 ` Gerd Möllmann
@ 2025-02-04 20:13 ` Eli Zaretskii
2025-02-04 20:34 ` Gerd Möllmann
0 siblings, 1 reply; 38+ messages in thread
From: Eli Zaretskii @ 2025-02-04 20:13 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: rudalics, 76031
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 76031@debbugs.gnu.org
> Date: Tue, 04 Feb 2025 19:31:20 +0100
>
> martin rudalics <rudalics@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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-04 20:10 ` Eli Zaretskii
@ 2025-02-04 20:22 ` Eli Zaretskii
2025-02-04 20:32 ` Gerd Möllmann
2025-02-04 20:31 ` Gerd Möllmann
2025-02-05 8:31 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2 siblings, 1 reply; 38+ messages in thread
From: Eli Zaretskii @ 2025-02-04 20:22 UTC (permalink / raw)
To: gerd.moellmann, rudalics; +Cc: 76031
> Cc: rudalics@gmx.at, 76031@debbugs.gnu.org
> Date: Tue, 04 Feb 2025 22:10:48 +0200
> From: Eli Zaretskii <eliz@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?
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-04 20:10 ` Eli Zaretskii
2025-02-04 20:22 ` Eli Zaretskii
@ 2025-02-04 20:31 ` Gerd Möllmann
2025-02-05 8:31 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2 siblings, 0 replies; 38+ messages in thread
From: Gerd Möllmann @ 2025-02-04 20:31 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rudalics, 76031
Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-04 20:22 ` Eli Zaretskii
@ 2025-02-04 20:32 ` Gerd Möllmann
0 siblings, 0 replies; 38+ messages in thread
From: Gerd Möllmann @ 2025-02-04 20:32 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rudalics, 76031
Eli Zaretskii <eliz@gnu.org> writes:
>> Cc: rudalics@gmx.at, 76031@debbugs.gnu.org
>> Date: Tue, 04 Feb 2025 22:10:48 +0200
>> From: Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-04 20:13 ` Eli Zaretskii
@ 2025-02-04 20:34 ` Gerd Möllmann
2025-02-05 3:27 ` Eli Zaretskii
0 siblings, 1 reply; 38+ messages in thread
From: Gerd Möllmann @ 2025-02-04 20:34 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rudalics, 76031
Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-04 20:34 ` Gerd Möllmann
@ 2025-02-05 3:27 ` Eli Zaretskii
2025-02-05 5:28 ` Gerd Möllmann
0 siblings, 1 reply; 38+ messages in thread
From: Eli Zaretskii @ 2025-02-05 3:27 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: rudalics, 76031
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: rudalics@gmx.at, 76031@debbugs.gnu.org
> Date: Tue, 04 Feb 2025 21:34:20 +0100
>
> Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-05 3:27 ` Eli Zaretskii
@ 2025-02-05 5:28 ` Gerd Möllmann
2025-02-05 13:57 ` Eli Zaretskii
0 siblings, 1 reply; 38+ messages in thread
From: Gerd Möllmann @ 2025-02-05 5:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rudalics, 76031
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: rudalics@gmx.at, 76031@debbugs.gnu.org
>> Date: Tue, 04 Feb 2025 21:34:20 +0100
>>
>> Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-04 20:10 ` Eli Zaretskii
2025-02-04 20:22 ` Eli Zaretskii
2025-02-04 20:31 ` Gerd Möllmann
@ 2025-02-05 8:31 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-05 8:58 ` Gerd Möllmann
2025-02-05 14:24 ` Eli Zaretskii
2 siblings, 2 replies; 38+ messages in thread
From: martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-05 8:31 UTC (permalink / raw)
To: Eli Zaretskii, Gerd Möllmann; +Cc: 76031
> 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
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-05 8:31 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-05 8:58 ` Gerd Möllmann
2025-02-05 14:24 ` Eli Zaretskii
1 sibling, 0 replies; 38+ messages in thread
From: Gerd Möllmann @ 2025-02-05 8:58 UTC (permalink / raw)
To: martin rudalics; +Cc: Eli Zaretskii, 76031
martin rudalics <rudalics@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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-04 14:30 ` Gerd Möllmann
2025-02-04 15:06 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-05 13:23 ` Eli Zaretskii
2025-02-05 13:43 ` Gerd Möllmann
1 sibling, 1 reply; 38+ messages in thread
From: Eli Zaretskii @ 2025-02-05 13:23 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: rudalics, 76031
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: rudalics@gmx.at, 76031@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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-05 13:23 ` Eli Zaretskii
@ 2025-02-05 13:43 ` Gerd Möllmann
2025-02-05 14:38 ` Eli Zaretskii
0 siblings, 1 reply; 38+ messages in thread
From: Gerd Möllmann @ 2025-02-05 13:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rudalics, 76031
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: rudalics@gmx.at, 76031@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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-05 5:28 ` Gerd Möllmann
@ 2025-02-05 13:57 ` Eli Zaretskii
2025-02-05 14:21 ` Gerd Möllmann
0 siblings, 1 reply; 38+ messages in thread
From: Eli Zaretskii @ 2025-02-05 13:57 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: rudalics, 76031
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: rudalics@gmx.at, 76031@debbugs.gnu.org
> Date: Wed, 05 Feb 2025 06:28:53 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> Cc: rudalics@gmx.at, 76031@debbugs.gnu.org
> >> Date: Tue, 04 Feb 2025 21:34:20 +0100
> >>
> >> Eli Zaretskii <eliz@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?
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-05 13:57 ` Eli Zaretskii
@ 2025-02-05 14:21 ` Gerd Möllmann
2025-02-05 14:41 ` Eli Zaretskii
0 siblings, 1 reply; 38+ messages in thread
From: Gerd Möllmann @ 2025-02-05 14:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rudalics, 76031
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: rudalics@gmx.at, 76031@debbugs.gnu.org
>> Date: Wed, 05 Feb 2025 06:28:53 +0100
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> >> Cc: rudalics@gmx.at, 76031@debbugs.gnu.org
>> >> Date: Tue, 04 Feb 2025 21:34:20 +0100
>> >>
>> >> Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-05 8:31 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-05 8:58 ` Gerd Möllmann
@ 2025-02-05 14:24 ` Eli Zaretskii
1 sibling, 0 replies; 38+ messages in thread
From: Eli Zaretskii @ 2025-02-05 14:24 UTC (permalink / raw)
To: martin rudalics; +Cc: gerd.moellmann, 76031
> Date: Wed, 5 Feb 2025 09:31:18 +0100
> Cc: 76031@debbugs.gnu.org
> From: martin rudalics <rudalics@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?
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-05 13:43 ` Gerd Möllmann
@ 2025-02-05 14:38 ` Eli Zaretskii
0 siblings, 0 replies; 38+ messages in thread
From: Eli Zaretskii @ 2025-02-05 14:38 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: rudalics, 76031
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: rudalics@gmx.at, 76031@debbugs.gnu.org
> Date: Wed, 05 Feb 2025 14:43:24 +0100
>
> Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-05 14:21 ` Gerd Möllmann
@ 2025-02-05 14:41 ` Eli Zaretskii
2025-02-05 15:05 ` Gerd Möllmann
0 siblings, 1 reply; 38+ messages in thread
From: Eli Zaretskii @ 2025-02-05 14:41 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: rudalics, 76031
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: rudalics@gmx.at, 76031@debbugs.gnu.org
> Date: Wed, 05 Feb 2025 15:21:50 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> Cc: rudalics@gmx.at, 76031@debbugs.gnu.org
> >> Date: Wed, 05 Feb 2025 06:28:53 +0100
> >>
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> >> Cc: rudalics@gmx.at, 76031@debbugs.gnu.org
> >> >> Date: Tue, 04 Feb 2025 21:34:20 +0100
> >> >>
> >> >> Eli Zaretskii <eliz@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?
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-05 14:41 ` Eli Zaretskii
@ 2025-02-05 15:05 ` Gerd Möllmann
2025-02-05 15:27 ` Eli Zaretskii
0 siblings, 1 reply; 38+ messages in thread
From: Gerd Möllmann @ 2025-02-05 15:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rudalics, 76031
Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-05 15:05 ` Gerd Möllmann
@ 2025-02-05 15:27 ` Eli Zaretskii
2025-02-05 17:13 ` Gerd Möllmann
0 siblings, 1 reply; 38+ messages in thread
From: Eli Zaretskii @ 2025-02-05 15:27 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: rudalics, 76031
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: rudalics@gmx.at, 76031@debbugs.gnu.org
> Date: Wed, 05 Feb 2025 16:05:26 +0100
>
> Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-05 15:27 ` Eli Zaretskii
@ 2025-02-05 17:13 ` Gerd Möllmann
2025-02-05 19:20 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 38+ messages in thread
From: Gerd Möllmann @ 2025-02-05 17:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rudalics, 76031
Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-05 17:13 ` Gerd Möllmann
@ 2025-02-05 19:20 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-05 20:24 ` Gerd Möllmann
0 siblings, 1 reply; 38+ messages in thread
From: martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-05 19:20 UTC (permalink / raw)
To: Gerd Möllmann, Eli Zaretskii; +Cc: 76031
> 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
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-05 19:20 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-05 20:24 ` Gerd Möllmann
2025-02-06 7:33 ` Gerd Möllmann
0 siblings, 1 reply; 38+ messages in thread
From: Gerd Möllmann @ 2025-02-05 20:24 UTC (permalink / raw)
To: martin rudalics; +Cc: Eli Zaretskii, 76031
martin rudalics <rudalics@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.
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-05 20:24 ` Gerd Möllmann
@ 2025-02-06 7:33 ` Gerd Möllmann
2025-02-06 9:39 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 38+ messages in thread
From: Gerd Möllmann @ 2025-02-06 7:33 UTC (permalink / raw)
To: martin rudalics; +Cc: Eli Zaretskii, 76031
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> martin rudalics <rudalics@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
^ permalink raw reply [flat|nested] 38+ messages in thread
* bug#76031: 31.0.50; Switching frames on TTY display doesn't work
2025-02-06 7:33 ` Gerd Möllmann
@ 2025-02-06 9:39 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 38+ messages in thread
From: martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-06 9:39 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: Eli Zaretskii, 76031
> 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
^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2025-02-06 9:39 UTC | newest]
Thread overview: 38+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-02-03 17:23 bug#76031: 31.0.50; Switching frames on TTY display doesn't work Eli Zaretskii
2025-02-03 19:20 ` Gerd Möllmann
2025-02-03 20:05 ` Eli Zaretskii
2025-02-04 8:09 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-04 8:46 ` Gerd Möllmann
2025-02-04 14:26 ` Eli Zaretskii
2025-02-04 14:30 ` Gerd Möllmann
2025-02-04 15:06 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-04 16:19 ` Eli Zaretskii
2025-02-04 17:54 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-04 18:27 ` Gerd Möllmann
2025-02-04 20:10 ` Eli Zaretskii
2025-02-04 20:22 ` Eli Zaretskii
2025-02-04 20:32 ` Gerd Möllmann
2025-02-04 20:31 ` Gerd Möllmann
2025-02-05 8:31 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-05 8:58 ` Gerd Möllmann
2025-02-05 14:24 ` Eli Zaretskii
2025-02-04 18:31 ` Gerd Möllmann
2025-02-04 20:13 ` Eli Zaretskii
2025-02-04 20:34 ` Gerd Möllmann
2025-02-05 3:27 ` Eli Zaretskii
2025-02-05 5:28 ` Gerd Möllmann
2025-02-05 13:57 ` Eli Zaretskii
2025-02-05 14:21 ` Gerd Möllmann
2025-02-05 14:41 ` Eli Zaretskii
2025-02-05 15:05 ` Gerd Möllmann
2025-02-05 15:27 ` Eli Zaretskii
2025-02-05 17:13 ` Gerd Möllmann
2025-02-05 19:20 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-05 20:24 ` Gerd Möllmann
2025-02-06 7:33 ` Gerd Möllmann
2025-02-06 9:39 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-05 13:23 ` Eli Zaretskii
2025-02-05 13:43 ` Gerd Möllmann
2025-02-05 14:38 ` Eli Zaretskii
2025-02-04 14:25 ` Eli Zaretskii
2025-02-04 14:49 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.