GNU bug report logs -
#79960
31.0.50; xterm-mouse-mode makes invisible child frames visible
Previous Next
Reported by: Daniel Mendler <mail <at> daniel-mendler.de>
Date: Sun, 7 Dec 2025 18:06:02 UTC
Severity: normal
Found in version 31.0.50
Fixed in version 31.1
Done: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 79960 in the body.
You can then email your comments to 79960 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
rudalics <at> gmx.at, gerd.moellmann <at> gmail.com, bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Sun, 07 Dec 2025 18:06:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Daniel Mendler <mail <at> daniel-mendler.de>:
New bug report received and forwarded. Copy sent to
rudalics <at> gmx.at, gerd.moellmann <at> gmail.com, bug-gnu-emacs <at> gnu.org.
(Sun, 07 Dec 2025 18:06:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
When `xterm-mouse-mode' is enabled after creating terminal child frames,
invisible child frames are made visible again.
1. Start emacs -Q -nw
2. Execute in the scratch buffer:
#+begin_src emacs-lisp
(package-initialize)
(global-corfu-mode) ;; Completion popup using TTY child frames
#+end_src
3. Trigger completion. For example type "(def" M-TAB in the scratch
buffer. The Corfu popup appears. Press C-g to close.
4. Enable `xterm-mouse-mode'. A Corfu child ghost frame appears.
In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.49, cairo version 1.18.4) of 2025-12-06
Windowing system distributor 'The X.Org Foundation', version 11.0.12101016
System Description: Debian GNU/Linux 13 (trixie)
Configured using:
'configure --prefix=$HOME/.local/share/emacs
--without-compress-install --with-tree-sitter --with-native-compilation
--with-dbus --without-selinux --without-threads --disable-gc-mark-trace
--without-gsettings --without-gpm --with-cairo --with-cairo-xcb
--with-xinput2 --with-x-toolkit=gtk3 --without-toolkit-scroll-bars
'CFLAGS=-O3 -mtune=native -march=native''
Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG LIBOTF LIBSYSTEMD
LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SOUND SQLITE3 TIFF TREE_SITTER WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM
XRANDR GTK3 ZLIB
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Sun, 07 Dec 2025 18:24:03 GMT)
Full text and
rfc822 format available.
Message #8 received at 79960 <at> debbugs.gnu.org (full text, mbox):
> Cc: martin rudalics <rudalics <at> gmx.at>,
> Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Sun, 07 Dec 2025 19:04:28 +0100
> From: Daniel Mendler via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> When `xterm-mouse-mode' is enabled after creating terminal child frames,
> invisible child frames are made visible again.
>
> 1. Start emacs -Q -nw
> 2. Execute in the scratch buffer:
>
> #+begin_src emacs-lisp
> (package-initialize)
> (global-corfu-mode) ;; Completion popup using TTY child frames
> #+end_src
>
> 3. Trigger completion. For example type "(def" M-TAB in the scratch
> buffer. The Corfu popup appears. Press C-g to close.
>
> 4. Enable `xterm-mouse-mode'. A Corfu child ghost frame appears.
Why do you call it a "ghost frame"? Isn't it just one of the frames
on that terminal?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Sun, 07 Dec 2025 18:29:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 79960 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Cc: martin rudalics <rudalics <at> gmx.at>,
>> Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Date: Sun, 07 Dec 2025 19:04:28 +0100
>> From: Daniel Mendler via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> When `xterm-mouse-mode' is enabled after creating terminal child frames,
>> invisible child frames are made visible again.
>>
>> 1. Start emacs -Q -nw
>> 2. Execute in the scratch buffer:
>>
>> #+begin_src emacs-lisp
>> (package-initialize)
>> (global-corfu-mode) ;; Completion popup using TTY child frames
>> #+end_src
>>
>> 3. Trigger completion. For example type "(def" M-TAB in the scratch
>> buffer. The Corfu popup appears. Press C-g to close.
>>
>> 4. Enable `xterm-mouse-mode'. A Corfu child ghost frame appears.
>
> Why do you call it a "ghost frame"? Isn't it just one of the frames
> on that terminal?
Sorry for being unclear with my language. I meant that the child frame
unintentionally reappears as a "ghost", at the same position where the
child frame has been, before it was made invisible. This means
`xterm-mouse-mode' somehow interferes with TTY child frame visibility.
Daniel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Sun, 07 Dec 2025 19:01:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 79960 <at> debbugs.gnu.org (full text, mbox):
Daniel Mendler <mail <at> daniel-mendler.de> writes:
> When `xterm-mouse-mode' is enabled after creating terminal child frames,
> invisible child frames are made visible again.
>
> 1. Start emacs -Q -nw
> 2. Execute in the scratch buffer:
>
> #+begin_src emacs-lisp
> (package-initialize)
> (global-corfu-mode) ;; Completion popup using TTY child frames
> #+end_src
>
> 3. Trigger completion. For example type "(def" M-TAB in the scratch
> buffer. The Corfu popup appears. Press C-g to close.
>
> 4. Enable `xterm-mouse-mode'. A Corfu child ghost frame appears.
>
> In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> 3.24.49, cairo version 1.18.4) of 2025-12-06
> Windowing system distributor 'The X.Org Foundation', version 11.0.12101016
> System Description: Debian GNU/Linux 13 (trixie)
>
> Configured using:
> 'configure --prefix=$HOME/.local/share/emacs
> --without-compress-install --with-tree-sitter --with-native-compilation
> --with-dbus --without-selinux --without-threads --disable-gc-mark-trace
> --without-gsettings --without-gpm --with-cairo --with-cairo-xcb
> --with-xinput2 --with-x-toolkit=gtk3 --without-toolkit-scroll-bars
> 'CFLAGS=-O3 -mtune=native -march=native''
>
> Configured features:
> CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG LIBOTF LIBSYSTEMD
> LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
> SOUND SQLITE3 TIFF TREE_SITTER WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM
> XRANDR GTK3 ZLIB
This looks suspicious:
xt-mouse.el:
509 (defun turn-on-xterm-mouse-tracking-on-terminal (&optional terminal)
510 "Enable xterm mouse tracking on TERMINAL."
511 (when (and xterm-mouse-mode (eq t (terminal-live-p terminal))
512 ;; Avoid the initial terminal which is not a termcap device.
513 ;; FIXME: is there more elegant way to detect the initial
514 ;; terminal?
515 (not (string= (terminal-name terminal) "initial_terminal")))
516 (unless (terminal-parameter terminal 'xterm-mouse-mode)
517 ;; Simulate selecting a terminal by selecting one of its frames
518 ;; so that we can set the terminal-local `input-decode-map'.
519 (with-selected-frame (car (frames-on-display-list terminal))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
520 (define-key input-decode-map "\e[M" 'xterm-mouse-translate)
521 (define-key input-decode-map "\e[<" 'xterm-mouse-translate-extended))
This should end up in select-frame -> do_switch_frame. And I'd bet the
car is the Corfu frame because new frames are pushed on the list.
Anyway, I'll try to reproduce this tomorrow, but if you feel like it,
you could try
1 file changed, 1 insertion(+), 1 deletion(-)
lisp/xt-mouse.el | 2 +-
modified lisp/xt-mouse.el
@@ -516,7 +516,7 @@ turn-on-xterm-mouse-tracking-on-terminal
(unless (terminal-parameter terminal 'xterm-mouse-mode)
;; Simulate selecting a terminal by selecting one of its frames
;; so that we can set the terminal-local `input-decode-map'.
- (with-selected-frame (car (frames-on-display-list terminal))
+ (with-selected-frame (frame-root-frame (car (frames-on-display-list terminal)))
(define-key input-decode-map "\e[M" 'xterm-mouse-translate)
(define-key input-decode-map "\e[<" 'xterm-mouse-translate-extended))
(let ((enable (xterm-mouse-tracking-enable-sequence))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Sun, 07 Dec 2025 23:23:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 79960 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> This looks suspicious:
>
> xt-mouse.el:
> 509 (defun turn-on-xterm-mouse-tracking-on-terminal (&optional terminal)
> 510 "Enable xterm mouse tracking on TERMINAL."
> 511 (when (and xterm-mouse-mode (eq t (terminal-live-p terminal))
> 512 ;; Avoid the initial terminal which is not a termcap device.
> 513 ;; FIXME: is there more elegant way to detect the initial
> 514 ;; terminal?
> 515 (not (string= (terminal-name terminal) "initial_terminal")))
> 516 (unless (terminal-parameter terminal 'xterm-mouse-mode)
> 517 ;; Simulate selecting a terminal by selecting one of its frames
> 518 ;; so that we can set the terminal-local `input-decode-map'.
> 519 (with-selected-frame (car (frames-on-display-list terminal))
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 520 (define-key input-decode-map "\e[M" 'xterm-mouse-translate)
> 521 (define-key input-decode-map "\e[<" 'xterm-mouse-translate-extended))
>
> This should end up in select-frame -> do_switch_frame. And I'd bet the
> car is the Corfu frame because new frames are pushed on the list.
> Anyway, I'll try to reproduce this tomorrow, but if you feel like it,
> you could try
Thanks. Yes, the first frame in the list is the Corfu frame (I added
names to the Corfu frames for ease of debugging.)
> 1 file changed, 1 insertion(+), 1 deletion(-)
> lisp/xt-mouse.el | 2 +-
>
> modified lisp/xt-mouse.el
> @@ -516,7 +516,7 @@ turn-on-xterm-mouse-tracking-on-terminal
> (unless (terminal-parameter terminal 'xterm-mouse-mode)
> ;; Simulate selecting a terminal by selecting one of its frames
> ;; so that we can set the terminal-local `input-decode-map'.
> - (with-selected-frame (car (frames-on-display-list terminal))
> + (with-selected-frame (frame-root-frame (car (frames-on-display-list terminal)))
> (define-key input-decode-map "\e[M" 'xterm-mouse-translate)
> (define-key input-decode-map "\e[<" 'xterm-mouse-translate-extended))
> (let ((enable (xterm-mouse-tracking-enable-sequence))
With this change The Corfu frame still reappears.
Daniel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 03:50:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 79960 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Daniel Mendler <mail <at> daniel-mendler.de> writes:
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> lisp/xt-mouse.el | 2 +-
>>
>> modified lisp/xt-mouse.el
>> @@ -516,7 +516,7 @@ turn-on-xterm-mouse-tracking-on-terminal
>> (unless (terminal-parameter terminal 'xterm-mouse-mode)
>> ;; Simulate selecting a terminal by selecting one of its frames
>> ;; so that we can set the terminal-local `input-decode-map'.
>> - (with-selected-frame (car (frames-on-display-list terminal))
>> + (with-selected-frame (frame-root-frame (car (frames-on-display-list terminal)))
>> (define-key input-decode-map "\e[M" 'xterm-mouse-translate)
>> (define-key input-decode-map "\e[<" 'xterm-mouse-translate-extended))
>> (let ((enable (xterm-mouse-tracking-enable-sequence))
>
> With this change The Corfu frame still reappears.
Thanks for checking.
I could reduce this to a simpler test case that does not involve Corfu.
With emacs -Q -nw -l run-emacs.el, where run-emacs.el is attached.
- C-l create child frame
- C-l make child frame invisible
- M-x xterm-mouse-mode RET disable mode
- M-x xterm-mouse-mode RET enable mode
-> child frame is visible
I'll continue with this tomorrow.
[run-emacs.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 05:36:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 79960 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Daniel Mendler <mail <at> daniel-mendler.de> writes:
>
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> lisp/xt-mouse.el | 2 +-
>>>
>>> modified lisp/xt-mouse.el
>>> @@ -516,7 +516,7 @@ turn-on-xterm-mouse-tracking-on-terminal
>>> (unless (terminal-parameter terminal 'xterm-mouse-mode)
>>> ;; Simulate selecting a terminal by selecting one of its frames
>>> ;; so that we can set the terminal-local `input-decode-map'.
>>> - (with-selected-frame (car (frames-on-display-list terminal))
>>> + (with-selected-frame (frame-root-frame (car (frames-on-display-list terminal)))
>>> (define-key input-decode-map "\e[M" 'xterm-mouse-translate)
>>> (define-key input-decode-map "\e[<" 'xterm-mouse-translate-extended))
>>> (let ((enable (xterm-mouse-tracking-enable-sequence))
>>
>> With this change The Corfu frame still reappears.
>
> Thanks for checking.
>
> I could reduce this to a simpler test case that does not involve Corfu.
> With emacs -Q -nw -l run-emacs.el, where run-emacs.el is attached.
>
> - C-l create child frame
> - C-l make child frame invisible
> - M-x xterm-mouse-mode RET disable mode
> - M-x xterm-mouse-mode RET enable mode
>
> -> child frame is visible
>
> I'll continue with this tomorrow.
Or rather now, because of Deutsche Bahn :-/.
Anyway. Both my test case above without Corfu, and the Corfu case you
gave me are fixed for me in master with the change I posted already:
1 file changed, 1 insertion(+), 1 deletion(-)
lisp/xt-mouse.el | 2 +-
modified lisp/xt-mouse.el
@@ -515,7 +515,7 @@ turn-on-xterm-mouse-tracking-on-terminal
(unless (terminal-parameter terminal 'xterm-mouse-mode)
;; Simulate selecting a terminal by selecting one of its frames
;; so that we can set the terminal-local `input-decode-map'.
- (with-selected-frame (car (frames-on-display-list terminal))
+ (with-selected-frame (frame-root-frame (car (frames-on-display-list terminal)))
(define-key input-decode-map "\e[M" 'xterm-mouse-translate)
(define-key input-decode-map "\e[<" 'xterm-mouse-translate-extended))
(let ((enable (xterm-mouse-tracking-enable-sequence))
The select-frame calls do_switch_frame with the child frame and that
makes the frame visible here
frame.c:
1942 else
1943 {
1944 /* Should be covered by the condition above. */
1945 if (!FRAME_PARENT_FRAME (f))
1946 fprintf (stderr, "do_switch_frame: 2 make child visible (%d)\n", f->visible);
1947 SET_FRAME_VISIBLE (f, true);
1948 }
as I suspected.
For the Corfu test, I made me a new init directory in which I installed
only Corfu via package-install. Then
- emacs -nw --init-directory DIR
- M-x global-corfu-mode
- in scratch, type frame- M-TAB to pop up Corfu
- 2 times M-x xterm-mouse-mode to disable and enable again
This makes the Corfu frame visible without the patch above, and doesn't
with my change.
Could you please re-check? If it still doesn't work for you, I guess I
need more detailed instructions how I can provoke that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 06:49:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 79960 <at> debbugs.gnu.org (full text, mbox):
Thanks, Gerd.
I'll check again.
Daniel
Am 8. Dezember 2025 06:35:23 MEZ schrieb "Gerd Möllmann" <gerd.moellmann <at> gmail.com>:
>Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Daniel Mendler <mail <at> daniel-mendler.de> writes:
>>
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>> lisp/xt-mouse.el | 2 +-
>>>>
>>>> modified lisp/xt-mouse.el
>>>> @@ -516,7 +516,7 @@ turn-on-xterm-mouse-tracking-on-terminal
>>>> (unless (terminal-parameter terminal 'xterm-mouse-mode)
>>>> ;; Simulate selecting a terminal by selecting one of its frames
>>>> ;; so that we can set the terminal-local `input-decode-map'.
>>>> - (with-selected-frame (car (frames-on-display-list terminal))
>>>> + (with-selected-frame (frame-root-frame (car (frames-on-display-list terminal)))
>>>> (define-key input-decode-map "\e[M" 'xterm-mouse-translate)
>>>> (define-key input-decode-map "\e[<" 'xterm-mouse-translate-extended))
>>>> (let ((enable (xterm-mouse-tracking-enable-sequence))
>>>
>>> With this change The Corfu frame still reappears.
>>
>> Thanks for checking.
>>
>> I could reduce this to a simpler test case that does not involve Corfu.
>> With emacs -Q -nw -l run-emacs.el, where run-emacs.el is attached.
>>
>> - C-l create child frame
>> - C-l make child frame invisible
>> - M-x xterm-mouse-mode RET disable mode
>> - M-x xterm-mouse-mode RET enable mode
>>
>> -> child frame is visible
>>
>> I'll continue with this tomorrow.
>
>Or rather now, because of Deutsche Bahn :-/.
>
>Anyway. Both my test case above without Corfu, and the Corfu case you
>gave me are fixed for me in master with the change I posted already:
>
>1 file changed, 1 insertion(+), 1 deletion(-)
>lisp/xt-mouse.el | 2 +-
>
>modified lisp/xt-mouse.el
>@@ -515,7 +515,7 @@ turn-on-xterm-mouse-tracking-on-terminal
> (unless (terminal-parameter terminal 'xterm-mouse-mode)
> ;; Simulate selecting a terminal by selecting one of its frames
> ;; so that we can set the terminal-local `input-decode-map'.
>- (with-selected-frame (car (frames-on-display-list terminal))
>+ (with-selected-frame (frame-root-frame (car (frames-on-display-list terminal)))
> (define-key input-decode-map "\e[M" 'xterm-mouse-translate)
> (define-key input-decode-map "\e[<" 'xterm-mouse-translate-extended))
> (let ((enable (xterm-mouse-tracking-enable-sequence))
>
>The select-frame calls do_switch_frame with the child frame and that
>makes the frame visible here
>
>frame.c:
> 1942 else
> 1943 {
> 1944 /* Should be covered by the condition above. */
> 1945 if (!FRAME_PARENT_FRAME (f))
> 1946 fprintf (stderr, "do_switch_frame: 2 make child visible (%d)\n", f->visible);
> 1947 SET_FRAME_VISIBLE (f, true);
> 1948 }
>
>as I suspected.
>
>For the Corfu test, I made me a new init directory in which I installed
>only Corfu via package-install. Then
>
>- emacs -nw --init-directory DIR
>- M-x global-corfu-mode
>- in scratch, type frame- M-TAB to pop up Corfu
>- 2 times M-x xterm-mouse-mode to disable and enable again
>
>This makes the Corfu frame visible without the patch above, and doesn't
>with my change.
>
>Could you please re-check? If it still doesn't work for you, I guess I
>need more detailed instructions how I can provoke that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 08:37:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 79960 <at> debbugs.gnu.org (full text, mbox):
> - C-l create child frame
> - C-l make child frame invisible
> - M-x xterm-mouse-mode RET disable mode
> - M-x xterm-mouse-mode RET enable mode
>
> -> child frame is visible
I know we're doing that ever since. But why should
(let ((frame (make-frame)))
(make-frame-invisible frame)
(select-window (frame-root-window frame))
(set-window-buffer (selected-window) "*Messages*"))
get me a frame that shows *scratch* on a GUI and one that shows
*Messages* on a tty?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 08:49:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 79960 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> - C-l create child frame
>> - C-l make child frame invisible
>> - M-x xterm-mouse-mode RET disable mode
>> - M-x xterm-mouse-mode RET enable mode
>>
>> -> child frame is visible
>
> I know we're doing that ever since. But why should
>
> (let ((frame (make-frame)))
> (make-frame-invisible frame)
> (select-window (frame-root-window frame))
> (set-window-buffer (selected-window) "*Messages*"))
>
> get me a frame that shows *scratch* on a GUI and one that shows
> *Messages* on a tty?
>
> martin
Strange.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 09:02:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 79960 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> martin rudalics <rudalics <at> gmx.at> writes:
>
>>> - C-l create child frame
>>> - C-l make child frame invisible
>>> - M-x xterm-mouse-mode RET disable mode
>>> - M-x xterm-mouse-mode RET enable mode
>>>
>>> -> child frame is visible
>>
>> I know we're doing that ever since. But why should
>>
>> (let ((frame (make-frame)))
>> (make-frame-invisible frame)
>> (select-window (frame-root-window frame))
>> (set-window-buffer (selected-window) "*Messages*"))
>>
>> get me a frame that shows *scratch* on a GUI and one that shows
>> *Messages* on a tty?
>>
>> martin
>
> Strange.
Could this be because GUIs have some windows that the tty doesn't have?
I don't remember the details, but I think there was some stuff in
dispnew.c where things could be a window in one case, and not in the
other case.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 09:07:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 79960 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> martin rudalics <rudalics <at> gmx.at> writes:
>>
>>>> - C-l create child frame
>>>> - C-l make child frame invisible
>>>> - M-x xterm-mouse-mode RET disable mode
>>>> - M-x xterm-mouse-mode RET enable mode
>>>>
>>>> -> child frame is visible
>>>
>>> I know we're doing that ever since. But why should
>>>
>>> (let ((frame (make-frame)))
>>> (make-frame-invisible frame)
>>> (select-window (frame-root-window frame))
>>> (set-window-buffer (selected-window) "*Messages*"))
>>>
>>> get me a frame that shows *scratch* on a GUI and one that shows
>>> *Messages* on a tty?
>>>
>>> martin
>>
>> Strange.
>
> Could this be because GUIs have some windows that the tty doesn't have?
> I don't remember the details, but I think there was some stuff in
> dispnew.c where things could be a window in one case, and not in the
> other case.
This stuff
frame.h:
246 #if defined HAVE_WINDOW_SYSTEM && !defined HAVE_EXT_MENU_BAR
247 /* A dummy window used to display menu bars under X when no X
248 toolkit support is available. */
249 Lisp_Object menu_bar_window;
250 #endif
251
252 #if defined (HAVE_WINDOW_SYSTEM)
253 /* A window used to display the tab-bar of a frame. */
254 Lisp_Object tab_bar_window;
255
256 /* Desired and current contents displayed in that window. */
257 Lisp_Object desired_tab_bar_string;
258 Lisp_Object current_tab_bar_string;
259 #endif
260
261 #if defined (HAVE_WINDOW_SYSTEM) && ! defined (HAVE_EXT_TOOL_BAR)
262 /* A window used to display the tool-bar of a frame. */
263 Lisp_Object tool_bar_window;
264
265 /* Desired and current contents displayed in that window. */
266 Lisp_Object desired_tool_bar_string;
267 Lisp_Object current_tool_bar_string;
268 #endif
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 09:47:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 79960 <at> debbugs.gnu.org (full text, mbox):
> Could this be because GUIs have some windows that the tty doesn't have?
> I don't remember the details, but I think there was some stuff in
> dispnew.c where things could be a window in one case, and not in the
> other case.
It's because ever since do_switch_frame makes a tty frame visible and
leaves a GUI frame invisible. I'd like to know the reason for the
special behavior on ttys.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 09:59:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 79960 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Could this be because GUIs have some windows that the tty doesn't have?
>> I don't remember the details, but I think there was some stuff in
>> dispnew.c where things could be a window in one case, and not in the
>> other case.
>
> It's because ever since do_switch_frame makes a tty frame visible and
> leaves a GUI frame invisible. I'd like to know the reason for the
> special behavior on ttys.
I'm afraid I don't remember the details anymore. Some part of the
transition from having no child windows + the tri-state visibility
to having child windows ond boolean visibility.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 10:34:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 79960 <at> debbugs.gnu.org (full text, mbox):
> I'm afraid I don't remember the details anymore. Some part of the
> transition from having no child windows + the tri-state visibility
> to having child windows ond boolean visibility.
I meant why we make a normal tty frame visible when selecting it. IIUC
it's from
commit 9628b8878f46b2b7eeeb4f272d20f2e64de19f4a
Author: Károly Lőrentey <lorentey <at> elte.hu>
Date: Fri Dec 26 04:24:54 2003 +0000
(do_switch_frame): Handle terminal frame visibility.
and the current version is from
commit edfa7fa092c303265edeb2a0b530463cdfe63ab7
Author: Dmitry Antipov <dmantipov <at> yandex.ru>
Date: Thu Jan 24 09:41:28 2013 +0400
Drop async_visible and async_iconified fields of struct frame.
I nowhere see a motivation for the behavior yet we probably have to live
with it.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 11:06:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 79960 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> I'm afraid I don't remember the details anymore. Some part of the
>> transition from having no child windows + the tri-state visibility
>> to having child windows ond boolean visibility.
>
> I meant why we make a normal tty frame visible when selecting it. IIUC
> it's from
I assumed I was the culprit, sorry. Could have been, though :-).
>
> commit 9628b8878f46b2b7eeeb4f272d20f2e64de19f4a
> Author: Károly Lőrentey <lorentey <at> elte.hu>
> Date: Fri Dec 26 04:24:54 2003 +0000
>
> (do_switch_frame): Handle terminal frame visibility.
Wow, that's multi-tty, as early as 2003. Didn't know it's that old. I
must have already been gone then, so zero memories. And no chance to
understand what that does why.
> and the current version is from
>
> commit edfa7fa092c303265edeb2a0b530463cdfe63ab7
> Author: Dmitry Antipov <dmantipov <at> yandex.ru>
> Date: Thu Jan 24 09:41:28 2013 +0400
>
> Drop async_visible and async_iconified fields of struct frame.
>
> I nowhere see a motivation for the behavior yet we probably have to live
> with it.
>
> martin
Hm, one could of course just remove that making frames visible, and see
what happens. Could lead to a number of bugs, maybe, but OTOH, and at
least from my POV, it would be an improvement because it would remove 1
random mysteroious quirk.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 13:29:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 79960 <at> debbugs.gnu.org (full text, mbox):
> Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 79960 <at> debbugs.gnu.org
> Date: Mon, 8 Dec 2025 10:45:44 +0100
> From: martin rudalics via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> > Could this be because GUIs have some windows that the tty doesn't have?
> > I don't remember the details, but I think there was some stuff in
> > dispnew.c where things could be a window in one case, and not in the
> > other case.
>
> It's because ever since do_switch_frame makes a tty frame visible and
> leaves a GUI frame invisible. I'd like to know the reason for the
> special behavior on ttys.
I'm not sure we should go in this direction to solve this issue. IMO,
any code which uses with-selected-frame to select an arbitrary frame
should note whether that frame was invisible, and if so, make it
invisible again after it's done using the frame. Because, even if the
change suggested by Gerd solves this particular scenario, we will next
see a bug report about a terminal that has _all_ of its frames
invisible.
(And that's after I wonder what is so important about a situation
where the user turns on xterm-mouse-mode so late into the session.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 13:32:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 79960 <at> debbugs.gnu.org (full text, mbox):
> Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 79960 <at> debbugs.gnu.org
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Mon, 08 Dec 2025 12:05:30 +0100
>
> martin rudalics <rudalics <at> gmx.at> writes:
>
> >> I'm afraid I don't remember the details anymore. Some part of the
> >> transition from having no child windows + the tri-state visibility
> >> to having child windows ond boolean visibility.
> >
> > I meant why we make a normal tty frame visible when selecting it. IIUC
> > it's from
>
> I assumed I was the culprit, sorry. Could have been, though :-).
>
> >
> > commit 9628b8878f46b2b7eeeb4f272d20f2e64de19f4a
> > Author: Károly Lőrentey <lorentey <at> elte.hu>
> > Date: Fri Dec 26 04:24:54 2003 +0000
> >
> > (do_switch_frame): Handle terminal frame visibility.
>
> Wow, that's multi-tty, as early as 2003. Didn't know it's that old. I
> must have already been gone then, so zero memories. And no chance to
> understand what that does why.
>
> > and the current version is from
> >
> > commit edfa7fa092c303265edeb2a0b530463cdfe63ab7
> > Author: Dmitry Antipov <dmantipov <at> yandex.ru>
> > Date: Thu Jan 24 09:41:28 2013 +0400
> >
> > Drop async_visible and async_iconified fields of struct frame.
> >
> > I nowhere see a motivation for the behavior yet we probably have to live
> > with it.
> >
> > martin
>
> Hm, one could of course just remove that making frames visible, and see
> what happens. Could lead to a number of bugs, maybe, but OTOH, and at
> least from my POV, it would be an improvement because it would remove 1
> random mysteroious quirk.
AFAIR, we already tried that, when you introduced child frames on
TTYs. We went back because there were too many problems with that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 14:24:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 79960 <at> debbugs.gnu.org (full text, mbox):
> I'm not sure we should go in this direction to solve this issue. IMO,
> any code which uses with-selected-frame to select an arbitrary frame
> should note whether that frame was invisible, and if so, make it
> invisible again after it's done using the frame.
I'm pretty sure that we cannot change anything here. 'select-frame' on
a tty can now be seen as a synonym for making the frame visible, raising
and selecting it. Maybe we should explain that somewhere.
> Because, even if the
> change suggested by Gerd solves this particular scenario, we will next
> see a bug report about a terminal that has _all_ of its frames
> invisible.
Indeed. The do_switch_frame call in delete_frame might depend on it.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 14:36:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 79960 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 8 Dec 2025 15:23:28 +0100
> Cc: gerd.moellmann <at> gmail.com, mail <at> daniel-mendler.de, 79960 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
>
> > I'm not sure we should go in this direction to solve this issue. IMO,
> > any code which uses with-selected-frame to select an arbitrary frame
> > should note whether that frame was invisible, and if so, make it
> > invisible again after it's done using the frame.
>
> I'm pretty sure that we cannot change anything here. 'select-frame' on
> a tty can now be seen as a synonym for making the frame visible, raising
> and selecting it. Maybe we should explain that somewhere.
What I meant was that in this code from xt-mouse.el:
;; Simulate selecting a terminal by selecting one of its frames
;; so that we can set the terminal-local `input-decode-map'.
(with-selected-frame (car (frames-on-display-list terminal))
(define-key input-decode-map "\e[M" 'xterm-mouse-translate)
(define-key input-decode-map "\e[<" 'xterm-mouse-translate-extended))
we should make the frame we select invisible again if it was invisible
before we selected it. IOW, select-frame should not change how it
works, but we should augment the code below to keep the frame
invisible. After all, we just picked up one frame to "simulate
selecting a terminal", we don't really care what that frame is and how
it is used.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 16:05:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 79960 <at> debbugs.gnu.org (full text, mbox):
> What I meant was that in this code from xt-mouse.el:
>
> ;; Simulate selecting a terminal by selecting one of its frames
> ;; so that we can set the terminal-local `input-decode-map'.
> (with-selected-frame (car (frames-on-display-list terminal))
> (define-key input-decode-map "\e[M" 'xterm-mouse-translate)
> (define-key input-decode-map "\e[<" 'xterm-mouse-translate-extended))
>
> we should make the frame we select invisible again if it was invisible
> before we selected it. IOW, select-frame should not change how it
> works, but we should augment the code below to keep the frame
> invisible. After all, we just picked up one frame to "simulate
> selecting a terminal", we don't really care what that frame is and how
> it is used.
Since on a tty there should be always at least one visible frame, we
could select a visible frame in the first place:
(with-selected-frame (car (filtered-frame-list
(lambda (frame)
(and (eq (frame-terminal frame) terminal)
(frame-visible-p frame)))))
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 16:15:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 79960 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> What I meant was that in this code from xt-mouse.el:
>>
>> ;; Simulate selecting a terminal by selecting one of its frames
>> ;; so that we can set the terminal-local `input-decode-map'.
>> (with-selected-frame (car (frames-on-display-list terminal))
>> (define-key input-decode-map "\e[M" 'xterm-mouse-translate)
>> (define-key input-decode-map "\e[<" 'xterm-mouse-translate-extended))
>>
>> we should make the frame we select invisible again if it was invisible
>> before we selected it. IOW, select-frame should not change how it
>> works, but we should augment the code below to keep the frame
>> invisible. After all, we just picked up one frame to "simulate
>> selecting a terminal", we don't really care what that frame is and how
>> it is used.
>
> Since on a tty there should be always at least one visible frame, we
> could select a visible frame in the first place:
>
> (with-selected-frame (car (filtered-frame-list
> (lambda (frame)
> (and (eq (frame-terminal frame) terminal)
> (frame-visible-p frame)))))
>
> martin
Hm. Aren't all child frames of an invisible root frame invisible?
How about, for this case, a function terminal-local-value analogous to
buffer-local-value? Iff Daniel confirms that this is the problem, which
he hasn't yet, and iff we want to fix this at all, given that
xterm-mouse-mode is on by default, and so on.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 16:36:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 79960 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 8 Dec 2025 17:03:46 +0100
> Cc: gerd.moellmann <at> gmail.com, mail <at> daniel-mendler.de, 79960 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
>
> > What I meant was that in this code from xt-mouse.el:
> >
> > ;; Simulate selecting a terminal by selecting one of its frames
> > ;; so that we can set the terminal-local `input-decode-map'.
> > (with-selected-frame (car (frames-on-display-list terminal))
> > (define-key input-decode-map "\e[M" 'xterm-mouse-translate)
> > (define-key input-decode-map "\e[<" 'xterm-mouse-translate-extended))
> >
> > we should make the frame we select invisible again if it was invisible
> > before we selected it. IOW, select-frame should not change how it
> > works, but we should augment the code below to keep the frame
> > invisible. After all, we just picked up one frame to "simulate
> > selecting a terminal", we don't really care what that frame is and how
> > it is used.
>
> Since on a tty there should be always at least one visible frame, we
> could select a visible frame in the first place:
>
> (with-selected-frame (car (filtered-frame-list
> (lambda (frame)
> (and (eq (frame-terminal frame) terminal)
> (frame-visible-p frame)))))
Didn't you just say that all TTY frames are "visible"?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 17:04:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 79960 <at> debbugs.gnu.org (full text, mbox):
> Hm. Aren't all child frames of an invisible root frame invisible?
Hopefully. But on a tty there must be always at least one visible
frame. On a GUI Emacs can make all frames invisible with the FORCE
argument.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 17:05:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 79960 <at> debbugs.gnu.org (full text, mbox):
>> Since on a tty there should be always at least one visible frame, we
>> could select a visible frame in the first place:
>>
>> (with-selected-frame (car (filtered-frame-list
>> (lambda (frame)
>> (and (eq (frame-terminal frame) terminal)
>> (frame-visible-p frame)))))
>
> Didn't you just say that all TTY frames are "visible"?
No. But IIRC this was the case before Gerd implemented child frames.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 17:08:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 79960 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Hm. Aren't all child frames of an invisible root frame invisible?
>
> Hopefully. But on a tty there must be always at least one visible
> frame. On a GUI Emacs can make all frames invisible with the FORCE
> argument.
>
Duh, right. Exactly one of the root frames of a terminal should always
be visible.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 17:10:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 79960 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 8 Dec 2025 18:03:45 +0100
> Cc: gerd.moellmann <at> gmail.com, mail <at> daniel-mendler.de, 79960 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
>
> >> Since on a tty there should be always at least one visible frame, we
> >> could select a visible frame in the first place:
> >>
> >> (with-selected-frame (car (filtered-frame-list
> >> (lambda (frame)
> >> (and (eq (frame-terminal frame) terminal)
> >> (frame-visible-p frame)))))
> >
> > Didn't you just say that all TTY frames are "visible"?
>
> No. But IIRC this was the case before Gerd implemented child frames.
Then why not simply use tty-top-frame?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 17:18:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 79960 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Mon, 8 Dec 2025 18:03:45 +0100
>> Cc: gerd.moellmann <at> gmail.com, mail <at> daniel-mendler.de, 79960 <at> debbugs.gnu.org
>> From: martin rudalics <rudalics <at> gmx.at>
>>
>> >> Since on a tty there should be always at least one visible frame, we
>> >> could select a visible frame in the first place:
>> >>
>> >> (with-selected-frame (car (filtered-frame-list
>> >> (lambda (frame)
>> >> (and (eq (frame-terminal frame) terminal)
>> >> (frame-visible-p frame)))))
>> >
>> > Didn't you just say that all TTY frames are "visible"?
>>
>> No. But IIRC this was the case before Gerd implemented child frames.
>
> Then why not simply use tty-top-frame?
Good idea.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Mon, 08 Dec 2025 18:05:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 79960 <at> debbugs.gnu.org (full text, mbox):
> Then why not simply use tty-top-frame?
Yes. This should work.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Tue, 09 Dec 2025 02:01:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 79960 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> Date: Mon, 8 Dec 2025 18:03:45 +0100
>>> Cc: gerd.moellmann <at> gmail.com, mail <at> daniel-mendler.de, 79960 <at> debbugs.gnu.org
>>> From: martin rudalics <rudalics <at> gmx.at>
>>>
>>> >> Since on a tty there should be always at least one visible frame, we
>>> >> could select a visible frame in the first place:
>>> >>
>>> >> (with-selected-frame (car (filtered-frame-list
>>> >> (lambda (frame)
>>> >> (and (eq (frame-terminal frame) terminal)
>>> >> (frame-visible-p frame)))))
>>> >
>>> > Didn't you just say that all TTY frames are "visible"?
>>>
>>> No. But IIRC this was the case before Gerd implemented child frames.
>>
>> Then why not simply use tty-top-frame?
>
> Good idea.
@Daniel could you please try this:
[0001-Don-t-make-a-tty-child-frame-visible-by-selecting-it.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Tue, 09 Dec 2025 12:22:03 GMT)
Full text and
rfc822 format available.
Message #95 received at 79960 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> Date: Mon, 8 Dec 2025 18:03:45 +0100
>>>> Cc: gerd.moellmann <at> gmail.com, mail <at> daniel-mendler.de, 79960 <at> debbugs.gnu.org
>>>> From: martin rudalics <rudalics <at> gmx.at>
>>>>
>>>> >> Since on a tty there should be always at least one visible frame, we
>>>> >> could select a visible frame in the first place:
>>>> >>
>>>> >> (with-selected-frame (car (filtered-frame-list
>>>> >> (lambda (frame)
>>>> >> (and (eq (frame-terminal frame) terminal)
>>>> >> (frame-visible-p frame)))))
>>>> >
>>>> > Didn't you just say that all TTY frames are "visible"?
>>>>
>>>> No. But IIRC this was the case before Gerd implemented child frames.
>>>
>>> Then why not simply use tty-top-frame?
>>
>> Good idea.
>
> @Daniel could you please try this:
Thanks Gerd! This works.
Daniel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79960; Package
emacs.
(Tue, 09 Dec 2025 12:26:03 GMT)
Full text and
rfc822 format available.
Message #98 received at 79960 <at> debbugs.gnu.org (full text, mbox):
Daniel Mendler <mail <at> daniel-mendler.de> writes:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>
>>>>> Date: Mon, 8 Dec 2025 18:03:45 +0100
>>>>> Cc: gerd.moellmann <at> gmail.com, mail <at> daniel-mendler.de, 79960 <at> debbugs.gnu.org
>>>>> From: martin rudalics <rudalics <at> gmx.at>
>>>>>
>>>>> >> Since on a tty there should be always at least one visible frame, we
>>>>> >> could select a visible frame in the first place:
>>>>> >>
>>>>> >> (with-selected-frame (car (filtered-frame-list
>>>>> >> (lambda (frame)
>>>>> >> (and (eq (frame-terminal frame) terminal)
>>>>> >> (frame-visible-p frame)))))
>>>>> >
>>>>> > Didn't you just say that all TTY frames are "visible"?
>>>>>
>>>>> No. But IIRC this was the case before Gerd implemented child frames.
>>>>
>>>> Then why not simply use tty-top-frame?
>>>
>>> Good idea.
>>
>> @Daniel could you please try this:
>
> Thanks Gerd! This works.
>
> Daniel
Thanks for testing!
I've oushed that to master, and closing.
bug marked as fixed in version 31.1, send any further explanations to
79960 <at> debbugs.gnu.org and Daniel Mendler <mail <at> daniel-mendler.de>
Request was from
Gerd Möllmann <gerd.moellmann <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Tue, 09 Dec 2025 12:26:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Wed, 07 Jan 2026 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified today.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.