GNU bug report logs -
#75056
31.0.50; tty-child-frames with server / multiple clients possible hangs
Previous Next
To reply to this bug, email your comments to 75056 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Tue, 24 Dec 2024 05:44:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Len Trigg <lenbok <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 24 Dec 2024 05:44:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
tty-child-frames does not seem to play well with multiple clients. When we
run server-start and allow emacs to have multiple clients (e.g. an initial
"emacs -nw" and an
"emacsclient -nw"), using a function that utilizes tty-child-frame (such as
M-x when vertico-posframe is loaded) in one frame leads the other client to
be locked up.
Steps to reproduce:
mkdir ~/emacs-test
Copy the attached init.el into ~/emacs-test/
emacs -nw --init-directory=~/emacs-test (the first time will result in
packages being installed by elpaca)
(in another terminal) emacsclient -nw
Do something to invoke the child frame pop up (e.g. C-x b and select a
buffer)
Switch back to the original emacs
Do something to invoke the child frame pop up (e.g. C-x b and select a
buffer)
Swap to the other terminal, and note that at some point one client will
stop responding
to user input. (It may take a couple of tries, perhaps with other regular
commands interspersed).
When one client is locked, swap back to the other terminal and exit the
client - the original
client will now accept user input.
When a client is locked it *does* accept some input (e.g. C-x C-c will exit
the client)
It's possible this is vertico-posframe related, as I can't trigger similar
behaviour using transient-posframe.
In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.41, cairo version 1.18.0) of 2024-12-24 built on kaka
Repository revision: 6ac38396898e6324d4c6dddb2ad05d1ad0dc5e7c
Repository branch: master
System Description: Ubuntu 24.04.1 LTS
Configured using:
'configure --prefix=/home/len/.local --with-rsvg --with-cairo
--with-native-compilation --with-tree-sitter --with-modules'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB
Important settings:
value of $LC_MONETARY: en_AU.UTF-8
value of $LC_NUMERIC: en_AU.UTF-8
value of $LC_TIME: en_AU.UTF-8
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Fundamental
Minor modes in effect:
xterm-mouse-mode: t
server-mode: t
vertico-posframe-mode: t
vertico-mode: t
elpaca-use-package-mode: t
override-global-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
blink-cursor-mode: t
minibuffer-regexp-mode: t
buffer-read-only: 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
Load-path shadows:
None found.
Features:
(shadow sort mail-extr compile comint ansi-osc ansi-color ring comp-run
comp-common rx emacsbug message yank-media puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util
text-property-search time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils xt-mouse term/xterm xterm
server vertico-posframe vertico-multiform vertico compat posframe
vertico-posframe-autoloads vertico-autoloads posframe-autoloads cl-extra
help-mode elpaca-use-package use-package use-package-ensure
use-package-delight use-package-diminish use-package-bind-key bind-key
easy-mmode use-package-core elpaca-use-package-autoloads elpaca-log
elpaca-ui elpaca-menu-elpa elpaca-menu-melpa url url-proxy url-privacy
url-expand url-methods url-history url-cookie generate-lisp-file
url-domsuf url-util url-parse auth-source cl-seq eieio eieio-core
cl-macs password-cache json subr-x map byte-opt gv bytecomp byte-compile
url-vars mailcap elpaca-menu-org elpaca warnings icons elpaca-process
cl-loaddefs cl-lib elpaca-autoloads 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 native-compile emacs)
Memory information:
((conses 16 396223 19518) (symbols 48 15669 0)
(strings 32 187599 3392) (string-bytes 1 2901786) (vectors 16 17588)
(vector-slots 8 194405 8250) (floats 8 78 41) (intervals 56 346 0)
(buffers 992 19))
[Message part 2 (text/html, inline)]
[init.el (text/x-emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Wed, 25 Dec 2024 11:58:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> From: Len Trigg <lenbok <at> gmail.com>
> Date: Tue, 24 Dec 2024 18:43:29 +1300
>
> tty-child-frames does not seem to play well with multiple clients. When we run server-start and allow emacs to
> have multiple clients (e.g. an initial "emacs -nw" and an
> "emacsclient -nw"), using a function that utilizes tty-child-frame (such as M-x when vertico-posframe is
> loaded) in one frame leads the other client to be locked up.
>
> Steps to reproduce:
>
> mkdir ~/emacs-test
> Copy the attached init.el into ~/emacs-test/
> emacs -nw --init-directory=~/emacs-test (the first time will result in packages being installed by elpaca)
> (in another terminal) emacsclient -nw
> Do something to invoke the child frame pop up (e.g. C-x b and select a buffer)
> Switch back to the original emacs
> Do something to invoke the child frame pop up (e.g. C-x b and select a buffer)
> Swap to the other terminal, and note that at some point one client will stop responding
> to user input. (It may take a couple of tries, perhaps with other regular commands interspersed).
> When one client is locked, swap back to the other terminal and exit the client - the original
> client will now accept user input.
>
> When a client is locked it *does* accept some input (e.g. C-x C-c will exit the client)
>
> It's possible this is vertico-posframe related, as I can't trigger similar behaviour using transient-posframe.
Gerd, could you perhaps look into this?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Wed, 25 Dec 2024 12:01:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Len Trigg <lenbok <at> gmail.com>
>> Date: Tue, 24 Dec 2024 18:43:29 +1300
>>
>> tty-child-frames does not seem to play well with multiple clients. When we run server-start and allow emacs to
>> have multiple clients (e.g. an initial "emacs -nw" and an
>> "emacsclient -nw"), using a function that utilizes tty-child-frame (such as M-x when vertico-posframe is
>> loaded) in one frame leads the other client to be locked up.
>>
>> Steps to reproduce:
>>
>> mkdir ~/emacs-test
>> Copy the attached init.el into ~/emacs-test/
>> emacs -nw --init-directory=~/emacs-test (the first time will result in packages being installed by elpaca)
>> (in another terminal) emacsclient -nw
>> Do something to invoke the child frame pop up (e.g. C-x b and select a buffer)
>> Switch back to the original emacs
>> Do something to invoke the child frame pop up (e.g. C-x b and select a buffer)
>> Swap to the other terminal, and note that at some point one client will stop responding
>> to user input. (It may take a couple of tries, perhaps with other regular commands interspersed).
>> When one client is locked, swap back to the other terminal and exit the client - the original
>> client will now accept user input.
>>
>> When a client is locked it *does* accept some input (e.g. C-x C-c will exit the client)
>>
>> It's possible this is vertico-posframe related, as I can't trigger similar behaviour using transient-posframe.
>
> Gerd, could you perhaps look into this?
Thanks. Will come back to this after the holidays.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 27 Dec 2024 06:07:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Len Trigg <lenbok <at> gmail.com> writes:
> tty-child-frames does not seem to play well with multiple clients. When we run server-start and allow emacs to have
> multiple clients (e.g. an initial "emacs -nw" and an
> "emacsclient -nw"), using a function that utilizes tty-child-frame (such as M-x when vertico-posframe is loaded) in one
> frame leads the other client to be locked up.
>
> Steps to reproduce:
>
> mkdir ~/emacs-test
> Copy the attached init.el into ~/emacs-test/
> emacs -nw --init-directory=~/emacs-test (the first time will result in packages being installed by elpaca)
> (in another terminal) emacsclient -nw
> Do something to invoke the child frame pop up (e.g. C-x b and select a buffer)
> Switch back to the original emacs
> Do something to invoke the child frame pop up (e.g. C-x b and select a buffer)
> Swap to the other terminal, and note that at some point one client will stop responding
> to user input. (It may take a couple of tries, perhaps with other regular commands interspersed).
> When one client is locked, swap back to the other terminal and exit the client - the original
> client will now accept user input.
>
> When a client is locked it *does* accept some input (e.g. C-x C-c will exit the client)
>
> It's possible this is vertico-posframe related, as I can't trigger similar behaviour using transient-posframe.
>
Hi Len, and thanks for the nice reproducer!
I can reproduce what you describe, I think, but I must admit that I'm a
bit at a loss at the moment. Something similar happens BTW if the server
is a GUI Emacs. Pretty weird.
And then I found this in admin/notes/multi-tty, under known problems:
* The single-kboard mode.
If your multi-tty Emacs session seems to be frozen, you
probably have a recursive editing session or a pending
minibuffer prompt (which is a kind of recursive editing) on
another display. To unfreeze your session, switch to that
display and complete the recursive edit, for example by
pressing C-] ('abort-recursive-edit').
I am sorry to say that currently there is no way to break
out of this "single-kboard mode" from a frozen display. If
you are unable to switch to the display that locks the
others (for example because it is on a remote computer),
then you can use emacsclient to break out of all recursive
editing sessions:
emacsclient -e '(top-level)'
Note that this (perhaps) unintuitive behavior is by design.
Single-kboard mode is required because of an intrinsic Emacs
limitation that is very hard to eliminate. (This limitation
is related to the single-threaded nature of Emacs.)
I plan to implement better user notification and support for
breaking out of single-kboard mode from locked displays.
Also see the long list of things to do in the same file, which makes me
a bit wary.
@Eli: I think we should invoke a multi-tty expert who can tell if what
we see here can be kind of expected with the current state of multi-tty or
not. And maybe can tell how up-to-date admin/notes/multi-tty is in the
first place.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 27 Dec 2024 08:19:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> Cc: 75056 <at> debbugs.gnu.org
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Fri, 27 Dec 2024 07:04:54 +0100
>
> I can reproduce what you describe, I think, but I must admit that I'm a
> bit at a loss at the moment. Something similar happens BTW if the server
> is a GUI Emacs. Pretty weird.
>
> And then I found this in admin/notes/multi-tty, under known problems:
>
> * The single-kboard mode.
>
> If your multi-tty Emacs session seems to be frozen, you
> probably have a recursive editing session or a pending
> minibuffer prompt (which is a kind of recursive editing) on
> another display. To unfreeze your session, switch to that
> display and complete the recursive edit, for example by
> pressing C-] ('abort-recursive-edit').
>
> I am sorry to say that currently there is no way to break
> out of this "single-kboard mode" from a frozen display. If
> you are unable to switch to the display that locks the
> others (for example because it is on a remote computer),
> then you can use emacsclient to break out of all recursive
> editing sessions:
>
> emacsclient -e '(top-level)'
>
> Note that this (perhaps) unintuitive behavior is by design.
> Single-kboard mode is required because of an intrinsic Emacs
> limitation that is very hard to eliminate. (This limitation
> is related to the single-threaded nature of Emacs.)
>
> I plan to implement better user notification and support for
> breaking out of single-kboard mode from locked displays.
>
> Also see the long list of things to do in the same file, which makes me
> a bit wary.
Can you explain how the above limitation causes the problem reported
in this bug? That is, how do child frames trigger the bug? Because
"normal" frames don't, AFAIU, right? That is, one could have two or
more client TTY frames on several displays in the same Emacs session,
without having any of them stop being responsive, right? Also, what
is the role of vertico-posframe in this scenario?
IOW, I don't yet have a clear picture of what happens, although the
limitations you found in that admin file are known to me. AFAIK, the
single-kboard situation is still with us, search keyboard.c for
"single_kboard".
> @Eli: I think we should invoke a multi-tty expert who can tell if what
> we see here can be kind of expected with the current state of multi-tty or
> not. And maybe can tell how up-to-date admin/notes/multi-tty is in the
> first place.
We don't have such an expert on board, sadly, not for a long while.
We are on our own.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 27 Dec 2024 08:49:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Can you explain how the above limitation causes the problem reported
> in this bug? That is, how do child frames trigger the bug? Because
> "normal" frames don't, AFAIU, right? That is, one could have two or
> more client TTY frames on several displays in the same Emacs session,
> without having any of them stop being responsive, right? Also, what
> is the role of vertico-posframe in this scenario?
The hint I see is here
>> If your multi-tty Emacs session seems to be frozen, you
>> probably have a recursive editing session or a pending
>> minibuffer prompt (which is a kind of recursive editing) on
>> another display.
Emacs in our case is kind of frozen, and Vertico is a minibuffer
interaction, where Posframe simply displays the minibuffer differently,
in a child frame.
Not an explanation of course, but it smells a lot like what's happening.
What the real reason behind all this is in the code, and what would need
to be fixed, I can't figure out from notes/multi-tty. Maybe come
combination of open things mentioned there, no idea.
>
> IOW, I don't yet have a clear picture of what happens, although the
> limitations you found in that admin file are known to me. AFAIK, the
> single-kboard situation is still with us, search keyboard.c for
> "single_kboard".
>
>> @Eli: I think we should invoke a multi-tty expert who can tell if what
>> we see here can be kind of expected with the current state of multi-tty or
>> not. And maybe can tell how up-to-date admin/notes/multi-tty is in the
>> first place.
>
> We don't have such an expert on board, sadly, not for a long while.
> We are on our own.
That's indeed more than suboptimal :-(.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 27 Dec 2024 08:55:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> Date: Fri, 27 Dec 2024 09:46:48 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Can you explain how the above limitation causes the problem reported
> > in this bug? That is, how do child frames trigger the bug? Because
> > "normal" frames don't, AFAIU, right? That is, one could have two or
> > more client TTY frames on several displays in the same Emacs session,
> > without having any of them stop being responsive, right? Also, what
> > is the role of vertico-posframe in this scenario?
>
> The hint I see is here
>
> >> If your multi-tty Emacs session seems to be frozen, you
> >> probably have a recursive editing session or a pending
> >> minibuffer prompt (which is a kind of recursive editing) on
> >> another display.
>
> Emacs in our case is kind of frozen, and Vertico is a minibuffer
> interaction, where Posframe simply displays the minibuffer differently,
> in a child frame.
Yes, but where is that recursive editing in this scenario?
I guess I'd love to see a C backtrace from that situation.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 27 Dec 2024 09:06:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
>> Date: Fri, 27 Dec 2024 09:46:48 +0100
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > Can you explain how the above limitation causes the problem reported
>> > in this bug? That is, how do child frames trigger the bug? Because
>> > "normal" frames don't, AFAIU, right? That is, one could have two or
>> > more client TTY frames on several displays in the same Emacs session,
>> > without having any of them stop being responsive, right? Also, what
>> > is the role of vertico-posframe in this scenario?
>>
>> The hint I see is here
>>
>> >> If your multi-tty Emacs session seems to be frozen, you
>> >> probably have a recursive editing session or a pending
>> >> minibuffer prompt (which is a kind of recursive editing) on
>> >> another display.
>>
>> Emacs in our case is kind of frozen, and Vertico is a minibuffer
>> interaction, where Posframe simply displays the minibuffer differently,
>> in a child frame.
>
> Yes, but where is that recursive editing in this scenario?
We're switching frames while being in the minibuffer in the other frame.
> I guess I'd love to see a C backtrace from that situation.
Too difficult for me. Emacs is not frozen in the sense that it is
completely stuck somewhere. For example, C-x C-c apparently always
works. C-g seems to work sometimes too, sometimes not. It's more like
the keyboard input doesn't land where it is supposed to. Or something
like that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 27 Dec 2024 12:30:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> Date: Fri, 27 Dec 2024 10:04:29 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> >> Cc: lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> >> Date: Fri, 27 Dec 2024 09:46:48 +0100
> >>
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>
> >> > Can you explain how the above limitation causes the problem reported
> >> > in this bug? That is, how do child frames trigger the bug? Because
> >> > "normal" frames don't, AFAIU, right? That is, one could have two or
> >> > more client TTY frames on several displays in the same Emacs session,
> >> > without having any of them stop being responsive, right? Also, what
> >> > is the role of vertico-posframe in this scenario?
> >>
> >> The hint I see is here
> >>
> >> >> If your multi-tty Emacs session seems to be frozen, you
> >> >> probably have a recursive editing session or a pending
> >> >> minibuffer prompt (which is a kind of recursive editing) on
> >> >> another display.
> >>
> >> Emacs in our case is kind of frozen, and Vertico is a minibuffer
> >> interaction, where Posframe simply displays the minibuffer differently,
> >> in a child frame.
> >
> > Yes, but where is that recursive editing in this scenario?
>
> We're switching frames while being in the minibuffer in the other frame.
>
> > I guess I'd love to see a C backtrace from that situation.
>
> Too difficult for me. Emacs is not frozen in the sense that it is
> completely stuck somewhere. For example, C-x C-c apparently always
> works. C-g seems to work sometimes too, sometimes not. It's more like
> the keyboard input doesn't land where it is supposed to. Or something
> like that.
Then why is this a bug?
When a frame is in a minibuffer, it means Emacs asks the user about
something, and in that situation, the user must respond to the prompt,
or exit the minibuffer in some other way. That's normal in my book.
What am I missing?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 27 Dec 2024 12:49:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Then why is this a bug?
>
> When a frame is in a minibuffer, it means Emacs asks the user about
> something, and in that situation, the user must respond to the prompt,
> or exit the minibuffer in some other way. That's normal in my book.
> What am I missing?
Emacs doesn't say anything. The user is just typing into the void, and
it's not easy get out of this state again, except C-x C-c. That's not
normal.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 27 Dec 2024 13:03:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> Date: Fri, 27 Dec 2024 13:47:09 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Then why is this a bug?
> >
> > When a frame is in a minibuffer, it means Emacs asks the user about
> > something, and in that situation, the user must respond to the prompt,
> > or exit the minibuffer in some other way. That's normal in my book.
> > What am I missing?
>
> Emacs doesn't say anything.
It does: on the frame where you are in the minibuffer.
> The user is just typing into the void, and it's not easy get out of
> this state again, except C-x C-c. That's not normal.
My point is that this happens in many other, "simpler" situations.
AFAIK, it isn't limited to TTY frames, either. So if that's the only
thing that happens here, i.e. some other frame is parked at the
minibuffer prompt, there's nothing new here that we didn't have before
child frames became supported on TTY displays. Changing that would
need to have per-frame input queues in Emacs, AFAIU, and some way of
multiplexing between them.
But I'm not yet sure this is what we see in this case, which is why I
asked for a C backtrace. Producing it should be easy: just reproduce
the problem, then attach a debugger and produce the backtrace.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 27 Dec 2024 13:19:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> But I'm not yet sure this is what we see in this case, which is why I
> asked for a C backtrace. Producing it should be easy: just reproduce
> the problem, then attach a debugger and produce the backtrace.
See below. AFAICS, Emacs is waiting for input, and when we have some,
the wrong things will happen. Please note that this is not a full debug
build.
bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
frame #0: 0x0000000190be51a8 libsystem_kernel.dylib`__pselect + 8
frame #1: 0x0000000190be5080 libsystem_kernel.dylib`pselect$DARWIN_EXTSN + 64
frame #2: 0x00000001047181d4 emacs`really_call_select(arg=0x000000016b8d44e0) at thread.c:620:16 [opt]
frame #3: 0x0000000104718148 emacs`thread_select [inlined] flush_stack_call_func(func=<unavailable>, arg=0x000000016b8d44e0) at lisp.h:4842:3 [opt]
frame #4: 0x0000000104718138 emacs`thread_select(func=<unavailable>, max_fds=<unavailable>, rfds=<unavailable>, wfds=<unavailable>, efds=<unavailable>, timeout=<unavailable>, sigmask=<unavailable>) at thread.c:652:3 [opt]
frame #5: 0x000000010473ef04 emacs`ns_select_1(nfds=<unavailable>, readfds=<unavailable>, writefds=<unavailable>, exceptfds=<unavailable>, timeout=<unavailable>, sigmask=<unavailable>, run_loop_only=<unavailable>) at nsterm.m:4873:12 [opt] [artificial]
frame #6: 0x000000010473ed14 emacs`ns_select(nfds=<unavailable>, readfds=<unavailable>, writefds=<unavailable>, exceptfds=<unavailable>, timeout=<unavailable>, sigmask=<unavailable>) at nsterm.m:5006:10 [opt] [artificial]
frame #7: 0x00000001046e72c0 emacs`wait_reading_process_output(time_limit=<unavailable>, nsecs=<unavailable>, read_kbd=<unavailable>, do_display=true, wait_for_cell=<unavailable>, wait_proc=<unavailable>, just_wait_proc=<unavailable>) at process.c:5766:18 [opt]
frame #8: 0x000000010460d4b4 emacs`read_char [inlined] kbd_buffer_get_event(kbp=<unavailable>, used_mouse_menu=0x000000016b8d4f67, end_time=0x0000000000000000) at keyboard.c:0 [opt]
!gud 0::/Users/gerd/emacs/github/cl-packages/src/keyboard.c
frame #9: 0x000000010460d294 emacs`read_char [inlined] read_event_from_main_queue(end_time=0x0000000000000000, local_getcjmp=0x000000016b8d4c00, used_mouse_menu=0x000000016b8d4f67) at keyboard.c:2336:7 [opt]
frame #10: 0x000000010460d134 emacs`read_char [inlined] read_decoded_event_from_main_queue(end_time=0x0000000000000000, local_getcjmp=0x000000016b8d4c00, prev_event=(struct Lisp_Symbol *) $4 = 0x0000000104e060e0, used_mouse_menu=0x000000016b8d4f67) at keyboard.c:2400:11 [opt]
frame #11: 0x000000010460d114 emacs`read_char(commandflag=1, map=(struct Lisp_Cons *) $8 = 0x000000010abc8280, prev_event=(struct Lisp_Symbol *) $4 = 0x0000000104e060e0, used_mouse_menu=0x000000016b8d4f67, end_time=0x0000000000000000) at keyboard.c:3031:11 [opt]
frame #12: 0x000000010460992c emacs`read_key_sequence(keybuf=<unavailable>, prompt=(struct Lisp_Symbol *) $4 = 0x0000000104e060e0, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=<unavailable>, disable_text_conversion_p=<unavailable>) at keyboard.c:10762:12 [opt]
frame #13: 0x0000000104607d9c emacs`command_loop_1 at keyboard.c:1435:15 [opt]
frame #14: 0x000000010468eeb0 emacs`internal_condition_case(bfun=(emacs`command_loop_1 at keyboard.c:1330), handlers=(struct Lisp_Symbol *) $10 = 0x0000000104e06188, hfun=(emacs`cmd_error at keyboard.c:976)) at eval.c:1669:25 [opt]
frame #15: 0x0000000104607a50 emacs`command_loop_2(handlers=(struct Lisp_Symbol *) $10 = 0x0000000104e06188) at keyboard.c:1174:11 [opt]
!gud 1174:11:/Users/gerd/emacs/github/cl-packages/src/keyboard.c
frame #16: 0x000000010468e504 emacs`internal_catch(tag=(struct Lisp_Symbol *) $13 = 0x0000000104e0f108, func=(emacs`command_loop_2 at keyboard.c:1170), arg=(struct Lisp_Symbol *) $10 = 0x0000000104e06188) at eval.c:1348:25 [opt]
frame #17: 0x000000010460714c emacs`command_loop at keyboard.c:1144:13 [opt]
frame #18: 0x0000000104607008 emacs`recursive_edit_1 at keyboard.c:760:9 [opt]
frame #19: 0x000000010463e660 emacs`Fread_from_minibuffer [inlined] read_minibuf(map=<unavailable>, initial=<unavailable>, prompt=(struct Lisp_String *) $15 = 0x000000010aba19a8, expflag=<unavailable>, histvar=<unavailable>, histpos=(EMACS_INT) $17 = 0, defalt=<unavailable>, allow_props=<unavailable>, inherit_input_method=<unavailable>) at minibuf.c:905:3 [opt]
!gud 905:3:/Users/gerd/emacs/github/cl-packages/src/minibuf.c
frame #20: 0x000000010463de28 emacs`Fread_from_minibuffer(prompt=(struct Lisp_String *) $15 = 0x000000010aba19a8, initial_contents=<unavailable>, keymap=(struct Lisp_Cons *) $18 = 0x0000000108f15eb0, read=(struct Lisp_Symbol *) $4 = 0x0000000104e060e0, hist=<unavailable>, default_value=(struct Lisp_String *) $19 = 0x000000010893a840, inherit_input_method=(struct Lisp_Symbol *) $4 = 0x0000000104e060e0) at minibuf.c:1398:9 [opt]
frame #21: 0x0000000104691b70 emacs`funcall_subr(subr=0x0000000104da0e70, numargs=7, args=<unavailable>) at eval.c:3237:15 [opt]
frame #22: 0x00000001046de5f0 emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:828:14 [opt]
frame #23: 0x0000000104691d0c emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=<unavailable>) at eval.c:3316:9 [opt] [artificial]
frame #24: 0x0000000104691a40 emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at eval.c:3108:12 [opt] [artificial]
frame #25: 0x000000010468c3f8 emacs`Ffuncall(nargs=9, args=(struct Lisp_Symbol *) $21 = 0x00000002706db770) at eval.c:3157:21 [opt]
frame #26: 0x0000000104690cac emacs`Fapply(nargs=1, args=(struct Lisp_Symbol *) $25 = 0x0000000244e0e360) at eval.c:2822:24 [opt]
frame #27: 0x0000000104691ac8 emacs`funcall_subr(subr=0x0000000104da72b0, numargs=1, args=<unavailable>) at eval.c:0 [opt]
frame #28: 0x00000001046de5f0 emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:828:14 [opt]
frame #29: 0x0000000104691d0c emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=<unavailable>) at eval.c:3316:9 [opt] [artificial]
frame #30: 0x0000000104691a40 emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at eval.c:3108:12 [opt] [artificial]
frame #31: 0x000000010468c3f8 emacs`Ffuncall(nargs=10, args=(struct Lisp_Symbol *) $29 = 0x00000002706db9d0) at eval.c:3157:21 [opt]
frame #32: 0x0000000104690cac emacs`Fapply(nargs=2, args=(struct Lisp_Symbol *) $32 = 0x0000000244e0e2d0) at eval.c:2822:24 [opt]
frame #33: 0x0000000104691ac8 emacs`funcall_subr(subr=0x0000000104da72b0, numargs=2, args=<unavailable>) at eval.c:0 [opt]
frame #34: 0x00000001046de5f0 emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:828:14 [opt]
frame #35: 0x0000000104691d0c emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=<unavailable>) at eval.c:3316:9 [opt] [artificial]
frame #36: 0x0000000104691a40 emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at eval.c:3108:12 [opt] [artificial]
frame #37: 0x000000010468c3f8 emacs`Ffuncall(nargs=10, args=(struct Lisp_Symbol *) $35 = 0x00000002706dbc30) at eval.c:3157:21 [opt]
frame #38: 0x0000000104690cac emacs`Fapply(nargs=3, args=(struct Lisp_Symbol *) $39 = 0x0000000244e0e280) at eval.c:2822:24 [opt]
frame #39: 0x0000000104691ac8 emacs`funcall_subr(subr=0x0000000104da72b0, numargs=3, args=<unavailable>) at eval.c:0 [opt]
frame #40: 0x00000001046de5f0 emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:828:14 [opt]
frame #41: 0x0000000104691d0c emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=<unavailable>) at eval.c:3316:9 [opt] [artificial]
frame #42: 0x0000000104691a40 emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at eval.c:3108:12 [opt] [artificial]
!gud 3108:12:/Users/gerd/emacs/github/cl-packages/src/eval.c
frame #43: 0x000000010468c3f8 emacs`Ffuncall(nargs=<unavailable>, args=(struct Lisp_Symbol *) $42 = 0x00000002706dbef0) at eval.c:3157:21 [opt]
frame #44: 0x000000010463f3c8 emacs`Fread_buffer(prompt=(struct Lisp_String *) $15 = 0x000000010aba19a8, def=(struct Lisp_String *) $19 = 0x000000010893a840, require_match=(struct Lisp_Symbol *) $45 = 0x00000001084b4d58, predicate=(struct Lisp_Symbol *) $4 = 0x0000000104e060e0) at minibuf.c:0 [opt]
frame #45: 0x0000000104691bdc emacs`funcall_subr(subr=0x0000000104da0fb0, numargs=3, args=<unavailable>) at eval.c:3231:15 [opt]
frame #46: 0x00000001046de5f0 emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:828:14 [opt]
!gud 828:14:/Users/gerd/emacs/github/cl-packages/src/bytecode.c
frame #47: 0x00000001046dd188 emacs`Fbyte_code(bytestr=<unavailable>, vector=(struct Lisp_Vector *) $48 = 0x00000001084b4808, maxdepth=(EMACS_INT) $50 = 4) at bytecode.c:325:10 [opt]
frame #48: 0x000000010468b8e8 emacs`eval_sub(form=(struct Lisp_Cons *) $51 = 0x00000001084b47a8) at eval.c:2661:15 [opt]
frame #49: 0x0000000104690798 emacs`Feval(form=<unavailable>, lexical=<unavailable>) at eval.c:2514:28 [opt]
frame #50: 0x0000000104688d84 emacs`Fcall_interactively(function=<unavailable>, record_flag=(struct Lisp_Symbol *) $4 = 0x0000000104e060e0, keys=(struct Lisp_Vector *) $52 = 0x000000010ab9ee88) at callint.c:325:15 [opt]
frame #51: 0x0000000104691c1c emacs`funcall_subr(subr=0x0000000104da68f0, numargs=3, args=<unavailable>) at eval.c:3229:15 [opt]
frame #52: 0x00000001046de5f0 emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:828:14 [opt]
frame #53: 0x0000000104691d0c emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=<unavailable>) at eval.c:3316:9 [opt] [artificial]
frame #54: 0x0000000104691a40 emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at eval.c:3108:12 [opt] [artificial]
frame #55: 0x000000010468c3f8 emacs`Ffuncall(nargs=2, args=(struct Lisp_Symbol *) $54 = 0x00000002706dc610) at eval.c:3157:21 [opt]
frame #56: 0x0000000104607fb0 emacs`command_loop_1 at keyboard.c:1556:13 [opt]
frame #57: 0x000000010468eeb0 emacs`internal_condition_case(bfun=(emacs`command_loop_1 at keyboard.c:1330), handlers=(struct Lisp_Symbol *) $10 = 0x0000000104e06188, hfun=(emacs`cmd_error at keyboard.c:976)) at eval.c:1669:25 [opt]
frame #58: 0x0000000104607a50 emacs`command_loop_2(handlers=(struct Lisp_Symbol *) $10 = 0x0000000104e06188) at keyboard.c:1174:11 [opt]
frame #59: 0x000000010468e504 emacs`internal_catch(tag=(struct Lisp_Symbol *) $58 = 0x0000000104e1aba0, func=(emacs`command_loop_2 at keyboard.c:1170), arg=(struct Lisp_Symbol *) $10 = 0x0000000104e06188) at eval.c:1348:25 [opt]
frame #60: 0x00000001046071c8 emacs`command_loop at keyboard.c:1152:2 [opt]
!gud 1152:2:/Users/gerd/emacs/github/cl-packages/src/keyboard.c
frame #61: 0x0000000104607008 emacs`recursive_edit_1 at keyboard.c:760:9 [opt]
frame #62: 0x000000010460740c emacs`Frecursive_edit at keyboard.c:843:3 [opt]
frame #63: 0x0000000104606134 emacs`main(argc=<unavailable>, argv=0x000000016b8d6c30) at emacs.c:2655:3 [opt]
frame #64: 0x00000001908a0274 dyld`start + 2840
(lldb)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 27 Dec 2024 14:54:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> Date: Fri, 27 Dec 2024 14:17:11 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > But I'm not yet sure this is what we see in this case, which is why I
> > asked for a C backtrace. Producing it should be easy: just reproduce
> > the problem, then attach a debugger and produce the backtrace.
>
> See below. AFAICS, Emacs is waiting for input, and when we have some,
> the wrong things will happen. Please note that this is not a full debug
> build.
Thanks. This lacks the equivalent of "xbacktrace", so a bit hard to
interpret, but I see read-from-minibuffer which called recursive-edit.
What is the recipe for this, starting from "emacs -Q", please? Can
this be reproduced without posframe?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 27 Dec 2024 15:58:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
>> Date: Fri, 27 Dec 2024 14:17:11 +0100
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > But I'm not yet sure this is what we see in this case, which is why I
>> > asked for a C backtrace. Producing it should be easy: just reproduce
>> > the problem, then attach a debugger and produce the backtrace.
>>
>> See below. AFAICS, Emacs is waiting for input, and when we have some,
>> the wrong things will happen. Please note that this is not a full debug
>> build.
>
> Thanks. This lacks the equivalent of "xbacktrace", so a bit hard to
> interpret, but I see read-from-minibuffer which called recursive-edit.
>
> What is the recipe for this, starting from "emacs -Q", please?
The one the OP gave is good.
> Can this be reproduced without posframe?
No idea.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 27 Dec 2024 18:15:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
(Sorry Eli for the dup email, I initially used Reply rather than Reply-All)
On Sat, 28 Dec 2024 at 02:02, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> > Cc: lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> > Date: Fri, 27 Dec 2024 13:47:09 +0100
> >
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> > > Then why is this a bug?
> > >
> > > When a frame is in a minibuffer, it means Emacs asks the user about
> > > something, and in that situation, the user must respond to the prompt,
> > > or exit the minibuffer in some other way. That's normal in my book.
> > > What am I missing?
> >
> > Emacs doesn't say anything.
>
> It does: on the frame where you are in the minibuffer.
>
Hmmm, the repro scenario I gave doesn't involve either emacs client being
still in the minibuffer AFAIK - the "working" client is just in a regular
buffer (e.g. having been chosen via C-x b and selected), and the "hung"
client is, well, hung.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 27 Dec 2024 18:26:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, 28 Dec 2024 at 07:13, Len Trigg <lenbok <at> gmail.com> wrote:
> Hmmm, the repro scenario I gave doesn't involve either emacs client being
> still in the minibuffer AFAIK - the "working" client is just in a regular
> buffer (e.g. having been chosen via C-x b and selected), and the "hung"
> client is, well, hung.
>
To elaborate my steps:
emacs -nw --init-directory=~/emacs-test (the first time will result in
packages being installed by elpaca)
(in another terminal) emacsclient -nw
Then invoke the child frame pop up: (e.g. C-x b and C-n to select
*Messages* and RET). Now we're no longer in a minibuffer.
Switch back to the original emacs
Invoke the child frame pop up (e.g. C-x b and C-n to select *Messages* and
RET). Now we're no longer in a minibuffer.
Swap to the other terminal, and note that the client is "hung".
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sat, 28 Dec 2024 07:45:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> From: Len Trigg <lenbok <at> gmail.com>
> Date: Sat, 28 Dec 2024 07:11:35 +1300
>
> On Sat, 28 Dec 2024 at 02:02, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> > Cc: lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> > Date: Fri, 27 Dec 2024 13:47:09 +0100
> >
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> > > Then why is this a bug?
> > >
> > > When a frame is in a minibuffer, it means Emacs asks the user about
> > > something, and in that situation, the user must respond to the prompt,
> > > or exit the minibuffer in some other way. That's normal in my book.
> > > What am I missing?
> >
> > Emacs doesn't say anything.
>
> It does: on the frame where you are in the minibuffer.
>
> Hmmm, the repro scenario I gave doesn't involve either emacs client being still in the minibuffer AFAIK - the
> "working" client is just in a regular buffer (e.g. having been chosen via C-x b and selected), and the "hung"
> client is, well, hung.
Maybe you switched out of the minibuffer window, leaving the
minibuffer active? In which case switching back to the mini-window
and exiting the minibuffer prompt (with RET or C-g or some other way)
should "unhang" the other client. Is this indeed so?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sat, 28 Dec 2024 07:53:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> From: Len Trigg <lenbok <at> gmail.com>
> Date: Sat, 28 Dec 2024 07:23:52 +1300
> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
> 75056 <at> debbugs.gnu.org
>
> On Sat, 28 Dec 2024 at 07:13, Len Trigg <lenbok <at> gmail.com> wrote:
>
> Hmmm, the repro scenario I gave doesn't involve either emacs client being still in the minibuffer AFAIK -
> the "working" client is just in a regular buffer (e.g. having been chosen via C-x b and selected), and the
> "hung" client is, well, hung.
>
> To elaborate my steps:
> emacs -nw --init-directory=~/emacs-test (the first time will result in packages being installed by elpaca)
> (in another terminal) emacsclient -nw
> Then invoke the child frame pop up: (e.g. C-x b and C-n to select *Messages* and RET). Now we're no
> longer in a minibuffer.
> Switch back to the original emacs
> Invoke the child frame pop up (e.g. C-x b and C-n to select *Messages* and RET). Now we're no longer in a
> minibuffer.
> Swap to the other terminal, and note that the client is "hung".
Could you please extend your recipe so it starts from "emacs -nw -Q"?
See, I don't have posframe or elpaca installed and don't use them, and
don't want to install them just to reproduce and debug this problem.
What I can do is download the packages needed to reproduce this,
unpack them into some temporary directory, and manually load them
(with commands like "M-x load-file") into Emacs started with -Q.
Could you please provide a recipe like this which I could follow? And
please specify specific commands in the recipe, not "e.g.", so I could
make sure I'm following exactly the correct steps, and nothing else.
It is otherwise very hard for me to spend time on such bug reports,
because I first need to understand what packages are involved and how
to activate them, and that can take a lot of time for packages I never
used.
TIA
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sat, 28 Dec 2024 19:58:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, 28 Dec 2024 at 20:52, Eli Zaretskii <eliz <at> gnu.org> wrote:
> Could you please extend your recipe so it starts from "emacs -nw -Q"?
> See, I don't have posframe or elpaca installed and don't use them, and
> don't want to install them just to reproduce and debug this problem.
>
Unless there's something I'm missing, the init file and startup command I
provided did the installation of those files for you into a temporary
directory, so I thought that was the easiest self-contained path to
reproducing. Let me assume you've run it once that way initially in order
to fetch the packages (otherwise you can manually download the files if you
want and adjust the paths in the below command line, but be aware that you
need new enough versions of posframe that understands tty child frame).
Then to get a "emacs -nw -Q" initialization you can use the attached
test.el to do:
emacs -nw -Q --init-directory=~/emacs-test -l
~/emacs-test/elpaca/repos/vertico/vertico.el -l
~/emacs-test/elpaca/repos/vertico/extensions/vertico-multiform.el -l
~/emacs-test/elpaca/repos/posframe/posframe.el -l
~/emacs-test/elpaca/repos/vertico-posframe/vertico-posframe.el test.el
Then manually "eval" the remaining commands in test.el
(in another terminal) emacsclient -nw
Then invoke the child frame pop up: (C-x b and C-n to select *Messages* and
RET). Now we're no longer in a minibuffer.
Switch back to the original emacs terminal
Invoke the child frame pop up: (C-x b and C-n to select *Messages* and
RET). Now we're no longer in a minibuffer.
Swap to the emacsclient terminal, and note that the client is "hung".
I think this gives a specific enough recipe to minimally reproduce.
[Message part 2 (text/html, inline)]
[test.el (text/x-emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 05 Jan 2025 16:42:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> From: Len Trigg <lenbok <at> gmail.com>
> Date: Sun, 29 Dec 2024 08:55:51 +1300
> Cc: gerd.moellmann <at> gmail.com, 75056 <at> debbugs.gnu.org
>
> On Sat, 28 Dec 2024 at 20:52, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> Could you please extend your recipe so it starts from "emacs -nw -Q"?
> See, I don't have posframe or elpaca installed and don't use them, and
> don't want to install them just to reproduce and debug this problem.
>
> Unless there's something I'm missing, the init file and startup command I provided did the installation of those
> files for you into a temporary directory, so I thought that was the easiest self-contained path to reproducing.
> Let me assume you've run it once that way initially in order to fetch the packages (otherwise you can
> manually download the files if you want and adjust the paths in the below command line, but be aware that
> you need new enough versions of posframe that understands tty child frame). Then to get a "emacs -nw -Q"
> initialization you can use the attached test.el to do:
>
> emacs -nw -Q --init-directory=~/emacs-test -l ~/emacs-test/elpaca/repos/vertico/vertico.el -l ~
> /emacs-test/elpaca/repos/vertico/extensions/vertico-multiform.el -l ~
> /emacs-test/elpaca/repos/posframe/posframe.el -l ~
> /emacs-test/elpaca/repos/vertico-posframe/vertico-posframe.el test.el
>
> Then manually "eval" the remaining commands in test.el
> (in another terminal) emacsclient -nw
> Then invoke the child frame pop up: (C-x b and C-n to select *Messages* and RET). Now we're no longer in
> a minibuffer.
> Switch back to the original emacs terminal
> Invoke the child frame pop up: (C-x b and C-n to select *Messages* and RET). Now we're no longer in a
> minibuffer.
> Swap to the emacsclient terminal, and note that the client is "hung".
>
> I think this gives a specific enough recipe to minimally reproduce.
>
> (vertico-mode)
>
> (push '(tty-non-selected-cursor . t) vertico-posframe-parameters)
> (push '(undecorated . nil) vertico-posframe-parameters)
> (vertico-posframe-mode)
>
> (server-start)
I tried this now, but I don't think I see the problem you describe.
I donwloaded vertico, posframe, and vertico-posframe packages from GNU
ELPA -- are the versions available there new enough to reproduce the
problem? If not, where should I download these packages from?
Anyway, I can only observe a "hung" client if I forcibly switch from
an active minibuffer. That is, after "C-x b" I don't select a buffer,
I simply type "C-x o" to switch out of the mini-window. Then only the
client where I switched out of the mini-window can accept keyboard
input, the other one is "hung".
However, I can see the same situation even without these two packages:
if I start emacsclient, type "C-x b" there, and then "C-x o" to switch
away from the mini-window, Emacs on the other frame will stop responding
to keyboard input. This is expected: when Emacs has an active
minibuffer on some display, Emacs temporarily switches to the
"single-keyboard mode".
But I suspect this is not what you see, so I wonder what did I not do
to reproduce the problem you see.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Tue, 07 Jan 2025 18:06:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Please excuse the top reply, I am traveling and my phone email client is limited.
Eli, thanks for taking another look. AFAIK, posframe needs to be newer than what is released in ELPA. You can get the latest from <https://github.com/tumashu/posframe>
I also think that if you had the older version you would not have seen a tty-child-frame at all and so not have triggered the bug I see - In your test did C-x b bring up a tty child frame in the center of the window, or a regular minibuffer at the bottom of the screen?
(You are correct that I did not switch away from the selector in my repro steps, I selected the buffer and exited normally with RET).
Cheers,
Len.
On 5 January 2025 6:41:15 pm GMT+02:00, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Len Trigg <lenbok <at> gmail.com>
>> Date: Sun, 29 Dec 2024 08:55:51 +1300
>> Cc: gerd.moellmann <at> gmail.com, 75056 <at> debbugs.gnu.org
>>
>> On Sat, 28 Dec 2024 at 20:52, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>> Could you please extend your recipe so it starts from "emacs -nw -Q"?
>> See, I don't have posframe or elpaca installed and don't use them, and
>> don't want to install them just to reproduce and debug this problem.
>>
>> Unless there's something I'm missing, the init file and startup command I provided did the installation of those
>> files for you into a temporary directory, so I thought that was the easiest self-contained path to reproducing.
>> Let me assume you've run it once that way initially in order to fetch the packages (otherwise you can
>> manually download the files if you want and adjust the paths in the below command line, but be aware that
>> you need new enough versions of posframe that understands tty child frame). Then to get a "emacs -nw -Q"
>> initialization you can use the attached test.el to do:
>>
>> emacs -nw -Q --init-directory=~/emacs-test -l ~/emacs-test/elpaca/repos/vertico/vertico.el -l ~
>> /emacs-test/elpaca/repos/vertico/extensions/vertico-multiform.el -l ~
>> /emacs-test/elpaca/repos/posframe/posframe.el -l ~
>> /emacs-test/elpaca/repos/vertico-posframe/vertico-posframe.el test.el
>>
>> Then manually "eval" the remaining commands in test.el
>> (in another terminal) emacsclient -nw
>> Then invoke the child frame pop up: (C-x b and C-n to select *Messages* and RET). Now we're no longer in
>> a minibuffer.
>> Switch back to the original emacs terminal
>> Invoke the child frame pop up: (C-x b and C-n to select *Messages* and RET). Now we're no longer in a
>> minibuffer.
>> Swap to the emacsclient terminal, and note that the client is "hung".
>>
>> I think this gives a specific enough recipe to minimally reproduce.
>>
>> (vertico-mode)
>>
>> (push '(tty-non-selected-cursor . t) vertico-posframe-parameters)
>> (push '(undecorated . nil) vertico-posframe-parameters)
>> (vertico-posframe-mode)
>>
>> (server-start)
>
>I tried this now, but I don't think I see the problem you describe.
>
>I donwloaded vertico, posframe, and vertico-posframe packages from GNU
>ELPA -- are the versions available there new enough to reproduce the
>problem? If not, where should I download these packages from?
>
>Anyway, I can only observe a "hung" client if I forcibly switch from
>an active minibuffer. That is, after "C-x b" I don't select a buffer,
>I simply type "C-x o" to switch out of the mini-window. Then only the
>client where I switched out of the mini-window can accept keyboard
>input, the other one is "hung".
>
>However, I can see the same situation even without these two packages:
>if I start emacsclient, type "C-x b" there, and then "C-x o" to switch
>away from the mini-window, Emacs on the other frame will stop responding
>to keyboard input. This is expected: when Emacs has an active
>minibuffer on some display, Emacs temporarily switches to the
>"single-keyboard mode".
>
>But I suspect this is not what you see, so I wonder what did I not do
>to reproduce the problem you see.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Thu, 23 Jan 2025 15:47:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, 8 Jan 2025 at 07:05, Len Trigg <lenbok <at> gmail.com> wrote:
> Eli, thanks for taking another look. AFAIK, posframe needs to be newer
> than what is released in ELPA. You can get the latest from <
> https://github.com/tumashu/posframe>
>
> I also think that if you had the older version you would not have seen a
> tty-child-frame at all and so not have triggered the bug I see - In your
> test did C-x b bring up a tty child frame in the center of the window, or a
> regular minibuffer at the bottom of the screen?
>
> (You are correct that I did not switch away from the selector in my repro
> steps, I selected the buffer and exited normally with RET).
>
I am back home from travelling and I see that emacs master has had several
changes related to tty child frames, so I rebuilt (as at commit
d83d090de11) and tried my test case again. Now rather than "blocking",
emacs segfaults with:
Fatal error 11: Segmentation fault
Backtrace:
emacs(+0x1b1e12)[0x64b571445e12]
emacs(+0x57927)[0x64b5712eb927]
emacs(+0x57e6a)[0x64b5712ebe6a]
emacs(+0x1aff58)[0x64b571443f58]
emacs(+0x1affdd)[0x64b571443fdd]
/lib/x86_64-linux-gnu/libc.so.6(+0x45320)[0x726c12045320]
emacs(+0x699ef)[0x64b5712fd9ef]
emacs(+0xb192b)[0x64b57134592b]
emacs(+0xb309d)[0x64b57134709d]
emacs(+0x1a569e)[0x64b57143969e]
emacs(+0x286cc6)[0x64b57151acc6]
emacs(+0x6d004)[0x64b571301004]
emacs(+0x1a074b)[0x64b57143474b]
emacs(+0x1a1ab7)[0x64b571435ab7]
emacs(+0x1a3714)[0x64b571437714]
emacs(+0x221547)[0x64b5714b5547]
emacs(+0x18ecde)[0x64b571422cde]
emacs(+0x221489)[0x64b5714b5489]
emacs(+0x18ec71)[0x64b571422c71]
emacs(+0x196ce5)[0x64b57142ace5]
emacs(+0x197084)[0x64b57142b084]
emacs(+0x60e3f)[0x64b5712f4e3f]
/lib/x86_64-linux-gnu/libc.so.6(+0x2a1ca)[0x726c1202a1ca]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b)[0x726c1202a28b]
emacs(+0x613e5)[0x64b5712f53e5]
Segmentation fault (core dumped)
Cheers,
Len.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Thu, 23 Jan 2025 16:01:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, 24 Jan 2025 at 04:45, Len Trigg <lenbok <at> gmail.com> wrote:
> Fatal error 11: Segmentation fault
> Backtrace:
> emacs(+0x1b1e12)[0x64b571445e12]
> emacs(+0x57927)[0x64b5712eb927]
> emacs(+0x57e6a)[0x64b5712ebe6a]
> emacs(+0x1aff58)[0x64b571443f58]
> emacs(+0x1affdd)[0x64b571443fdd]
> /lib/x86_64-linux-gnu/libc.so.6(+0x45320)[0x726c12045320]
> emacs(+0x699ef)[0x64b5712fd9ef]
> emacs(+0xb192b)[0x64b57134592b]
> emacs(+0xb309d)[0x64b57134709d]
> emacs(+0x1a569e)[0x64b57143969e]
> emacs(+0x286cc6)[0x64b57151acc6]
> emacs(+0x6d004)[0x64b571301004]
> emacs(+0x1a074b)[0x64b57143474b]
> emacs(+0x1a1ab7)[0x64b571435ab7]
> emacs(+0x1a3714)[0x64b571437714]
> emacs(+0x221547)[0x64b5714b5547]
> emacs(+0x18ecde)[0x64b571422cde]
> emacs(+0x221489)[0x64b5714b5489]
> emacs(+0x18ec71)[0x64b571422c71]
> emacs(+0x196ce5)[0x64b57142ace5]
> emacs(+0x197084)[0x64b57142b084]
> emacs(+0x60e3f)[0x64b5712f4e3f]
> /lib/x86_64-linux-gnu/libc.so.6(+0x2a1ca)[0x726c1202a1ca]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b)[0x726c1202a28b]
> emacs(+0x613e5)[0x64b5712f53e5]
> Segmentation fault (core dumped)
>
I'm really not familiar with C debugging, but I managed to run my case
under gdb and trigger the crash. "where" shows:
#0 combine_updates_for_frame (f=f <at> entry=0x555556ca8d58,
inhibit_scrolling=inhibit_scrolling <at> entry=false) at dispnew.c:3973
#1 0x000055555560592b in redisplay_internal () at xdisp.c:17702
#2 0x000055555560709d in redisplay_preserve_echo_area
(from_where=from_where <at> entry=8) at xdisp.c:17842
#3 0x00005555556f969e in detect_input_pending_run_timers
(do_display=do_display <at> entry=true) at keyboard.c:11579
#4 0x00005555557dacc6 in wait_reading_process_output
(time_limit=time_limit <at> entry=30, nsecs=nsecs <at> entry=0,
read_kbd=read_kbd <at> entry=-1, do_display=do_display <at> entry=true,
wait_for_cell=wait_for_cell <at> entry=0x0, wait_proc=wait_proc <at> entry=0x0,
just_wait_proc=0) at process.c:5862
#5 0x00005555555c1004 in sit_for (timeout=timeout <at> entry=0x7a,
reading=reading <at> entry=true, display_option=display_option <at> entry=1) at
dispnew.c:6894
#6 0x00005555556f474b in read_char
(commandflag=1, map=map <at> entry=0x7fffecb615b3, prev_event=0x0,
used_mouse_menu=used_mouse_menu <at> entry=0x7fffffffc6cb,
end_time=end_time <at> entry=0x0) at keyboard.c:2925
#7 0x00005555556f5ab7 in read_key_sequence
(keybuf=keybuf <at> entry=0x7fffffffc820, prompt=prompt <at> entry=0x0,
dont_downcase_last=dont_downcase_last <at> entry=false,
can_return_switch_frame=can_return_switch_frame <at> entry=true,
fix_current_buffer=fix_current_buffer <at> entry=true,
prevent_redisplay=prevent_redisplay <at> entry=false,
disable_text_conversion_p=false) at keyboard.c:10746
#8 0x00005555556f7714 in command_loop_1 () at keyboard.c:1424
#9 0x0000555555775547 in internal_condition_case
(bfun=bfun <at> entry=0x5555556f7550 <command_loop_1>,
handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x5555556eb170 <cmd_error>)
at eval.c:1607
#10 0x00005555556e2cde in command_loop_2 (handlers=handlers <at> entry=0x90) at
keyboard.c:1163
#11 0x0000555555775489 in internal_catch (tag=tag <at> entry=0x12360,
func=func <at> entry=0x5555556e2cb0 <command_loop_2>, arg=arg <at> entry=0x90) at
eval.c:1286
#12 0x00005555556e2c71 in command_loop () at keyboard.c:1141
#13 0x00005555556eace5 in recursive_edit_1 () at keyboard.c:749
#14 0x00005555556eb084 in Frecursive_edit () at keyboard.c:832
#15 0x00005555555b4e3f in main (argc=3, argv=<optimized out>) at
emacs.c:2628
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Thu, 23 Jan 2025 16:39:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> From: Len Trigg <lenbok <at> gmail.com>
> Date: Fri, 24 Jan 2025 05:00:33 +1300
> Cc: gerd.moellmann <at> gmail.com, 75056 <at> debbugs.gnu.org
>
> #0 combine_updates_for_frame (f=f <at> entry=0x555556ca8d58,
> inhibit_scrolling=inhibit_scrolling <at> entry=false) at dispnew.c:3973
The crash is here:
for (Lisp_Object tail = XCDR (z_order); CONSP (tail); tail = XCDR (tail))
{
topmost_child = XFRAME (XCAR (tail));
copy_child_glyphs (root, topmost_child);
}
What is the value of z_order?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Thu, 23 Jan 2025 17:35:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Len Trigg <lenbok <at> gmail.com>
>> Date: Fri, 24 Jan 2025 05:00:33 +1300
>> Cc: gerd.moellmann <at> gmail.com, 75056 <at> debbugs.gnu.org
>>
>> #0 combine_updates_for_frame (f=f <at> entry=0x555556ca8d58,
>> inhibit_scrolling=inhibit_scrolling <at> entry=false) at dispnew.c:3973
>
> The crash is here:
>
> for (Lisp_Object tail = XCDR (z_order); CONSP (tail); tail = XCDR (tail))
> {
> topmost_child = XFRAME (XCAR (tail));
> copy_child_glyphs (root, topmost_child);
> }
>
> What is the value of z_order?
Len, can you please print
p root->visible
I have a suspicion that it might not be FRAME_VISIBLE_P. Alternatively,
you could configure with --enable-checking in which case we would see an
abort in combine_updates_for_frame.
The place in redisplay_internal where it is called is
if (mini_frame != sf)
{
XWINDOW (mini_window)->must_be_updated_p = true;
update_frame (mini_frame, false);
if (is_tty_frame (mini_frame))
combine_updates_for_frame (mini_frame, false);
mini_frame->cursor_type_changed = false;
There is no check for mini_frame being visible. At least not with a
quick look.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Thu, 23 Jan 2025 19:32:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, 24 Jan 2025 at 06:34, Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > What is the value of z_order?
>
> Len, can you please print
>
> p root->visible
>
(gdb) p root->visible
$1 = 0
(gdb) p z_order
$2 = (Lisp_Object) 0x0
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Thu, 23 Jan 2025 19:39:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Len Trigg <lenbok <at> gmail.com> writes:
> On Fri, 24 Jan 2025 at 06:34, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > What is the value of z_order?
>
> Len, can you please print
>
> p root->visible
>
> (gdb) p root->visible
> $1 = 0
> (gdb) p z_order
> $2 = (Lisp_Object) 0x0
Thanks, that explains the crash. I would never had expected that we
try to update invisible frames, hence the assert with --enable-checking
at the start of the function.
Now, the $1000 question is why is mini_frame in redisplay_internal
invisible? Pretty sure it has something to do with multi-tty.
Anyway. I'll develop a fix for that immediate problem tomorrow. I think
I'll just make it not crash for now, and perform the update anyway,
which I guess 30 would do.
Thanks!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Thu, 23 Jan 2025 20:01:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> From: Len Trigg <lenbok <at> gmail.com>
> Date: Fri, 24 Jan 2025 08:31:10 +1300
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 75056 <at> debbugs.gnu.org
>
> On Fri, 24 Jan 2025 at 06:34, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > What is the value of z_order?
>
> Len, can you please print
>
> p root->visible
>
> (gdb) p root->visible
> $1 = 0
> (gdb) p z_order
> $2 = (Lisp_Object) 0x0
So the crash is because we don't verify z_order is a cons cell before
we take its cdr.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 24 Jan 2025 05:27:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Anyway. I'll develop a fix for that immediate problem tomorrow. I think
> I'll just make it not crash for now, and perform the update anyway,
> which I guess 30 would do.
Pushed to master.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 24 Jan 2025 09:27:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
OK, that's fixed the crash, but my original problem persists, with a new
artifact. This time slightly different repro steps to make things more
visible:
- Open two terminal windows side by side
- In the first terminal: emacs -nw --init-directory=~/emacs-test (using
the original init.el I sent)
- In the second terminal: emacsclient -nw, followed by C-x b C-n RET (to
switch buffers using tty child frame, leaving the cursor in *Messages* and
the tty child frame has been dismissed)
- Back to the first terminal: C-x b C-n RET (as above, this switches
buffers using the tty child frame, leaving the cursor in *Messages* and the
tty child frame has been dismissed.
- Now, notice that immediately upon switching focus back to the second
terminal (I use focus follows mouse) we find the emacsclient "hung", but
back on the first terminal the tty child frame has magically represented
itself even though it had been dismissed!!!
- If we move the mouse focus back to the first terminal, the tty child
frame disappears.
On Fri, 24 Jan 2025 at 18:26, Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
> > Anyway. I'll develop a fix for that immediate problem tomorrow. I think
> > I'll just make it not crash for now, and perform the update anyway,
> > which I guess 30 would do.
>
> Pushed to master.
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 24 Jan 2025 09:33:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Len Trigg <lenbok <at> gmail.com> writes:
> OK, that's fixed the crash, but my original problem persists, with a
> new artifact. This time slightly different repro steps to make things
> more visible:
Okay, that's what I intended to fix. Thanks for the feedback.
I think the rest of the behavior is somehow multi-tty. We talked about
that already. I don't think I'll tackle that, sorry.
>
> - Open two terminal windows side by side
> - In the first terminal: emacs -nw --init-directory=~/emacs-test
> (using the original init.el I sent)
> - In the second terminal: emacsclient -nw, followed by C-x b C-n RET
> (to switch buffers using tty child frame, leaving the cursor in
> *Messages* and the tty child frame has been dismissed)
> - Back to the first terminal: C-x b C-n RET (as above, this switches
> buffers using the tty child frame, leaving the cursor in *Messages*
> and the tty child frame has been dismissed.
> - Now, notice that immediately upon switching focus back to the second
> terminal (I use focus follows mouse) we find the emacsclient "hung",
> but back on the first terminal the tty child frame has magically
> represented itself even though it had been dismissed!!!
> - If we move the mouse focus back to the first terminal, the tty child
> frame disappears.
>
> On Fri, 24 Jan 2025 at 18:26, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
> > Anyway. I'll develop a fix for that immediate problem tomorrow. I think
> > I'll just make it not crash for now, and perform the update anyway,
> > which I guess 30 would do.
>
> Pushed to master.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 24 Jan 2025 19:08:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, 24 Jan 2025 at 22:32, Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:
> I think the rest of the behavior is somehow multi-tty. We talked about
> that already. I don't think I'll tackle that, sorry.
>
You mentioned in the earlier email about single-kboard mode being a
limitation too big to address, but I'm confused as to why the child tty
frame (minibuffer?) that the user had actually dismissed then magically
reappears when the focus was moved to another terminal. Is it that the
child tty frame needs to be fully destroyed upon dismissal? (Is that
something posframe could do?) Could you please provide a description of
what you think is actually happening?
Cheers,
Len.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 24 Jan 2025 19:20:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
BTW, I triggered another segfault (this time I had two terminal clients and
one gui client and was cycling focus between them):
0x00005555555bdf65 in is_in_matrix (y=48, x=2297, f=0x555556f60048) at
dispnew.c:3893
3893 if (x < 0 || x >= root->current_matrix->matrix_w || y < 0
(gdb) where
#0 0x00005555555bdf65 in is_in_matrix (y=48, x=2297, f=0x555556f60048) at
dispnew.c:3893
#1 is_cursor_obscured () at dispnew.c:3913
#2 terminal_cursor_magic (topmost_child=0x555556c1e900,
root=0x555556bacd08) at dispnew.c:3932
#3 combine_updates_for_frame (f=<optimized out>,
inhibit_scrolling=inhibit_scrolling <at> entry=false) at dispnew.c:3997
#4 0x00005555555be0f3 in combine_updates (roots=roots <at> entry=0x7fffec960b33)
at dispnew.c:4023
#5 0x00005555556054f6 in redisplay_internal () at xdisp.c:17599
#6 0x0000555555606fe9 in redisplay () at xdisp.c:16656
#7 0x00005555556f25ba in read_char (commandflag=1,
map=map <at> entry=0x7fffec962463,
prev_event=0x0, used_mouse_menu=used_mouse_menu <at> entry=0x7fffffffc6ab,
end_time=end_time <at> entry=0x0)
at keyboard.c:2672
#8 0x00005555556f5ad7 in read_key_sequence
(keybuf=keybuf <at> entry=0x7fffffffc800, prompt=prompt <at> entry=0x0,
dont_downcase_last=dont_downcase_last <at> entry=false,
can_return_switch_frame=can_return_switch_frame <at> entry=true,
fix_current_buffer=fix_current_buffer <at> entry=true,
prevent_redisplay=prevent_redisplay <at> entry=false,
disable_text_conversion_p=false) at keyboard.c:10746
#9 0x00005555556f7734 in command_loop_1 () at keyboard.c:1424
#10 0x0000555555775607 in internal_condition_case
(bfun=bfun <at> entry=0x5555556f7570
<command_loop_1>, handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x5555556eb190
<cmd_error>) at eval.c:1607
#11 0x00005555556e2cfe in command_loop_2 (handlers=handlers <at> entry=0x90) at
keyboard.c:1163
#12 0x0000555555775549 in internal_catch (tag=tag <at> entry=0x12360,
func=func <at> entry=0x5555556e2cd0 <command_loop_2>, arg=arg <at> entry=0x90) at
eval.c:1286
#13 0x00005555556e2c91 in command_loop () at keyboard.c:1141
#14 0x00005555556ead05 in recursive_edit_1 () at keyboard.c:749
#15 0x00005555556eb0a4 in Frecursive_edit () at keyboard.c:832
#16 0x00005555555b4e3f in main (argc=3, argv=<optimized out>) at
emacs.c:2628
On Fri, 24 Jan 2025 at 22:32, Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:
> Len Trigg <lenbok <at> gmail.com> writes:
>
> > OK, that's fixed the crash, but my original problem persists, with a
> > new artifact. This time slightly different repro steps to make things
> > more visible:
>
> Okay, that's what I intended to fix. Thanks for the feedback.
>
> I think the rest of the behavior is somehow multi-tty. We talked about
> that already. I don't think I'll tackle that, sorry.
>
> >
> > - Open two terminal windows side by side
>
> > - In the first terminal: emacs -nw --init-directory=~/emacs-test
> > (using the original init.el I sent)
>
> > - In the second terminal: emacsclient -nw, followed by C-x b C-n RET
> > (to switch buffers using tty child frame, leaving the cursor in
> > *Messages* and the tty child frame has been dismissed)
>
> > - Back to the first terminal: C-x b C-n RET (as above, this switches
> > buffers using the tty child frame, leaving the cursor in *Messages*
> > and the tty child frame has been dismissed.
>
> > - Now, notice that immediately upon switching focus back to the second
> > terminal (I use focus follows mouse) we find the emacsclient "hung",
> > but back on the first terminal the tty child frame has magically
> > represented itself even though it had been dismissed!!!
>
> > - If we move the mouse focus back to the first terminal, the tty child
> > frame disappears.
> >
> > On Fri, 24 Jan 2025 at 18:26, Gerd Möllmann <gerd.moellmann <at> gmail.com>
> wrote:
> >
> > Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> >
> > > Anyway. I'll develop a fix for that immediate problem tomorrow. I
> think
> > > I'll just make it not crash for now, and perform the update anyway,
> > > which I guess 30 would do.
> >
> > Pushed to master.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 24 Jan 2025 19:49:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Len Trigg <lenbok <at> gmail.com> writes:
> On Fri, 24 Jan 2025 at 22:32, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>
> I think the rest of the behavior is somehow multi-tty. We talked about
> that already. I don't think I'll tackle that, sorry.
>
> You mentioned in the earlier email about single-kboard mode being a
> limitation too big to address, but I'm confused as to why the child
> tty frame (minibuffer?) that the user had actually dismissed then
> magically reappears when the focus was moved to another terminal. Is
> it that the child tty frame needs to be fully destroyed upon
> dismissal? (Is that something posframe could do?) Could you please
> provide a description of what you think is actually happening?
I don't want to go down the rabbit hole of finding out what exactly is
happening, because that would mean I would begin to debug multi-tty,
which I wouldn't poke with a 2 meter stick after reading
admin/notes/multi-tty :-)
I have only one hint: the crash was because mini_frame in
redisplay_internal was invisible, and we updated it in
combined_update_for_frame. Updating an invisible frame logically makes
no sense, why is it invisible then? When that mini_frame is invisible,
is there another frame visible now that _should_ have been invisible
instead of mini_frame? If so, which one? And could it be that child
frames of that frame are now displayed? Possibly.
Question upon questions :-)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 24 Jan 2025 20:01:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Len Trigg <lenbok <at> gmail.com> writes:
> BTW, I triggered another segfault (this time I had two terminal clients and one gui client and was cycling focus between
> them):
>
> 0x00005555555bdf65 in is_in_matrix (y=48, x=2297, f=0x555556f60048) at dispnew.c:3893
> 3893 if (x < 0 || x >= root->current_matrix->matrix_w || y < 0
> (gdb) where
> #0 0x00005555555bdf65 in is_in_matrix (y=48, x=2297, f=0x555556f60048) at dispnew.c:3893
> #1 is_cursor_obscured () at dispnew.c:3913
Thanks for the report.
You either have a very wide display (x=...), or the selected frame at
this point is a GUI frame. I guess I can fix that over the weekend.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 24 Jan 2025 20:41:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, 25 Jan 2025 at 09:00, Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:
> You either have a very wide display (x=...), or the selected frame at
> this point is a GUI frame.
>
Or possibly both? (My monitor is 3440x1440, and I had it with the GUI
emacsclient frame in the rightmost third).
Thanks,
Len.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sat, 25 Jan 2025 03:47:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Len Trigg <lenbok <at> gmail.com> writes:
> On Sat, 25 Jan 2025 at 09:00, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>
> You either have a very wide display (x=...), or the selected frame at
> this point is a GUI frame.
>
>
> Or possibly both? (My monitor is 3440x1440, and I had it with the GUI emacsclient frame in the
> rightmost third).
At that point in the code, pixels == characters, so if that were a tty
frame, you'd need something like sub-pixel eyesight :-).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sat, 25 Jan 2025 07:03:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> You either have a very wide display (x=...), or the selected frame at
> this point is a GUI frame. I guess I can fix that over the weekend.
I've pushed something to master for the crash. Please give it a try.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sat, 25 Jan 2025 08:44:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 75056 <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:
>
>> You either have a very wide display (x=...), or the selected frame at
>> this point is a GUI frame. I guess I can fix that over the weekend.
>
> I've pushed something to master for the crash. Please give it a try.
I had to revert that for now because I have introduced a bug somewhere,
and can't fix this fast enough, sorry.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sat, 25 Jan 2025 13:48:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 75056 <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:
>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>>> You either have a very wide display (x=...), or the selected frame at
>>> this point is a GUI frame. I guess I can fix that over the weekend.
>>
>> I've pushed something to master for the crash. Please give it a try.
>
> I had to revert that for now because I have introduced a bug somewhere,
> and can't fix this fast enough, sorry.
Fix now on master.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sat, 25 Jan 2025 19:26:01 GMT)
Full text and
rfc822 format available.
Message #125 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thanks, so far I haven't been able to produce that segfault, so hopefully
fixed.
I noticed that the documentation for frame-visible-p says:
"If FRAME is a text terminal frame, this always returns t.
Such frames are always considered visible, whether or not they are
currently being displayed on the terminal."
I could see that prior to tty child frames that was necessarily true, but
now we have tty child frames shouldn't that documentation be updated? (I'm
assuming at the code level it's no longer true since posframe hides it's
frames by simply making them invisible).
Cheers,
Len.
On Sun, 26 Jan 2025 at 02:47, Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
> > Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> >
> >> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> >>
> >>> You either have a very wide display (x=...), or the selected frame at
> >>> this point is a GUI frame. I guess I can fix that over the weekend.
> >>
> >> I've pushed something to master for the crash. Please give it a try.
> >
> > I had to revert that for now because I have introduced a bug somewhere,
> > and can't fix this fast enough, sorry.
>
> Fix now on master.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sat, 25 Jan 2025 20:09:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Len Trigg <lenbok <at> gmail.com> writes:
> Thanks, so far I haven't been able to produce that segfault, so
> hopefully fixed.
Good to know, thanks for testing!
> I noticed that the documentation for frame-visible-p says:
>
> "If FRAME is a text terminal frame, this always returns t.
> Such frames are always considered visible, whether or not they are
> currently being displayed on the terminal."
>
> I could see that prior to tty child frames that was necessarily true,
> but now we have tty child frames shouldn't that documentation be
> updated? (I'm assuming at the code level it's no longer true since
> posframe hides it's frames by simply making them invisible).
Yes, that's right, The visibility thing on ttys is now more like on
GUIs. We have to change the documentation.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sat, 25 Jan 2025 22:40:03 GMT)
Full text and
rfc822 format available.
Message #131 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, 26 Jan 2025 at 09:08, Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:
> > I could see that prior to tty child frames that was necessarily true,
> > but now we have tty child frames shouldn't that documentation be
> > updated? (I'm assuming at the code level it's no longer true since
> > posframe hides it's frames by simply making them invisible).
>
> Yes, that's right, The visibility thing on ttys is now more like on
> GUIs. We have to change the documentation.
>
OK, so would I be correct that our current understanding of this bug is now
best described as "something is setting previously invisible tty child
frames as visible when focus changes to an alternative tty client"?
(Possibly some part of the multi-tty code that still assumes that all tty
frames are always visible). This then causes the non-focused client to
display the tty child frame with minibuffer that then blocks input from
other clients due to the existing single-kboard limitation.
Cheers,
Len.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 04:54:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Len Trigg <lenbok <at> gmail.com> writes:
> On Sun, 26 Jan 2025 at 09:08, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>
> > I could see that prior to tty child frames that was necessarily true,
> > but now we have tty child frames shouldn't that documentation be
> > updated? (I'm assuming at the code level it's no longer true since
> > posframe hides it's frames by simply making them invisible).
>
> Yes, that's right, The visibility thing on ttys is now more like on
> GUIs. We have to change the documentation.
>
> OK, so would I be correct that our current understanding of this bug
> is now best described as "something is setting previously invisible
> tty child frames as visible when focus changes to an alternative tty
> client"? (Possibly some part of the multi-tty code that still assumes
> that all tty frames are always visible). This then causes the
> non-focused client to display the tty child frame with minibuffer that
> then blocks input from other clients due to the existing single-kboard
> limitation.
"Understanding" is a bit much said, as far as I am concerned. If I
wanted to debug this, which I don't :-), my start hypotheses would be
that this has to do with the minibuffer, yes.
I would first try to find out what does multi-tty Emacs do when Posframe
is not involved. Say we have two frames F1 and F2 on different ttys. On
F1, I enter the minibuffer with C-x C-b for example, and open a
completion window. At that point, I switch to F2.
What would a user then expect? I can't really answer that question
because it's not a use-case I'm familiar with. Maybe the minibuffer
should somehow be "migrated" from F1 to F2? Including the completions
buffer? Or should Emacs display an error when we select F2 and maybe try
to switch back to F1? No idea. If the minibuffer is migrated to F2, what
would I expect to happen on F1? Closing the completions window, leaving
the minibuffer?
Then see admin/notes/multi-tty. What does it say about things? Or maybe
Elisp Info.
Then look at what really happens, and compare.
Find in the code what actually happens when switching from F1 to F2 and
compare that with admin/notes/multi-tty has to say about that. Does that
document say something about what we've seen the code doing? Open issues
maybe? Or general considerations?
I think only if that all works as expected, including Vertico and others
which play with the minibuffer, only then I would bring Posframe into
play.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 06:09:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 75056 <at> debbugs.gnu.org
> Date: Sat, 25 Jan 2025 21:08:48 +0100
>
> Len Trigg <lenbok <at> gmail.com> writes:
>
> > Thanks, so far I haven't been able to produce that segfault, so
> > hopefully fixed.
>
> Good to know, thanks for testing!
>
> > I noticed that the documentation for frame-visible-p says:
> >
> > "If FRAME is a text terminal frame, this always returns t.
> > Such frames are always considered visible, whether or not they are
> > currently being displayed on the terminal."
> >
> > I could see that prior to tty child frames that was necessarily true,
> > but now we have tty child frames shouldn't that documentation be
> > updated? (I'm assuming at the code level it's no longer true since
> > posframe hides it's frames by simply making them invisible).
>
> Yes, that's right, The visibility thing on ttys is now more like on
> GUIs. We have to change the documentation.
I see you already changed the doc string, by deleting the
special-casing text about TTY frames. But I'm not sure the situation
on TTY frames is identical to GUI frames, so maybe we still need some
special text about that. Also, there are other functions related to
frame visibility.
First, there's no "iconified" frames on TTYs, right? so this function
can never return 'icon' in that case, correct? And I presume
iconify-frame is a no-op for TTY frames?
More importantly, what frames could have this function return nil?
E.g., can a non-child frame return nil?
Also, what do make-frame-visible and raise-frame do with TTY frames
for which frame-visible-p returns nil, and what does
make-frame-invisible do for those TTY frames for which this function
returns non-nil?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 06:27:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> First, there's no "iconified" frames on TTYs, right? so this function
> can never return 'icon' in that case, correct? And I presume
> iconify-frame is a no-op for TTY frames?
Martin mentioned in passing that he thinks iconifying frames on ttys
should perhaps do something. So it's maybe a "not yet".
> More importantly, what frames could have this function return nil?
> E.g., can a non-child frame return nil?
Yes. C-x 5 2 can make a new root frame, and only one is visible on
the display.
> Also, what do make-frame-visible and raise-frame do with TTY frames
> for which frame-visible-p returns nil, and what does
> make-frame-invisible do for those TTY frames for which this function
> returns non-nil?
raise-frame is make-frame-visible + changing z-order, make-frame-visible
and make-frame-invisible change the "visible" flag. (Just notices
make-frame-visible talks about "X window", hm.).
Did you mean these doc strings should be changed, too, or did you mean
something else?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 07:34:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 75056 <at> debbugs.gnu.org
> Date: Sun, 26 Jan 2025 05:53:22 +0100
>
> Len Trigg <lenbok <at> gmail.com> writes:
>
> > OK, so would I be correct that our current understanding of this bug
> > is now best described as "something is setting previously invisible
> > tty child frames as visible when focus changes to an alternative tty
> > client"? (Possibly some part of the multi-tty code that still assumes
> > that all tty frames are always visible). This then causes the
> > non-focused client to display the tty child frame with minibuffer that
> > then blocks input from other clients due to the existing single-kboard
> > limitation.
>
> "Understanding" is a bit much said, as far as I am concerned. If I
> wanted to debug this, which I don't :-), my start hypotheses would be
> that this has to do with the minibuffer, yes.
>
> I would first try to find out what does multi-tty Emacs do when Posframe
> is not involved. Say we have two frames F1 and F2 on different ttys. On
> F1, I enter the minibuffer with C-x C-b for example, and open a
> completion window.
I guess you meant "C-x b TAB". "C-x C-b" doesn't activate the
minibuffer.
> At that point, I switch to F2.
>
> What would a user then expect?
What happens in this case is that F2 cannot be communicated with:
typing anything there gets no response, until we exit the minibuffer
on F1. Then everything you typed on F2 gets processed.
> Find in the code what actually happens when switching from F1 to F2 and
> compare that with admin/notes/multi-tty has to say about that. Does that
> document say something about what we've seen the code doing? Open issues
> maybe? Or general considerations?
What the code does when Emacs enters a minibuffer is switch to a
"single-keyboard mode", whereby it only processes keyboard input from
the frame which entered the minibuffer. This is because Emacs has
only one input queue.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 07:51:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> I would first try to find out what does multi-tty Emacs do when Posframe
>> is not involved. Say we have two frames F1 and F2 on different ttys. On
>> F1, I enter the minibuffer with C-x C-b for example, and open a
>> completion window.
>
> I guess you meant "C-x b TAB". "C-x C-b" doesn't activate the
> minibuffer.
Right, sorry, I forgot that I have consult-buffer on C-x b.
>> At that point, I switch to F2.
>>
>> What would a user then expect?
>
> What happens in this case is that F2 cannot be communicated with:
> typing anything there gets no response, until we exit the minibuffer
> on F1. Then everything you typed on F2 gets processed.
>
>> Find in the code what actually happens when switching from F1 to F2 and
>> compare that with admin/notes/multi-tty has to say about that. Does that
>> document say something about what we've seen the code doing? Open issues
>> maybe? Or general considerations?
>
> What the code does when Emacs enters a minibuffer is switch to a
> "single-keyboard mode", whereby it only processes keyboard input from
> the frame which entered the minibuffer. This is because Emacs has
> only one input queue.
I would perhaps check how that switching to single-kboard is done. That
is, which C functions do that, what does do_switch_frame do and so on.
And why does the mini_frame in redisplay_internal end up invisible? Is
F1 invisible now, and if so why?
And then see if that all is what admin/notes/multi-tty says is intended,
if there are open issues, and so on.
Something like that, maybe.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 07:58:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> Date: Sun, 26 Jan 2025 07:26:06 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > First, there's no "iconified" frames on TTYs, right? so this function
> > can never return 'icon' in that case, correct? And I presume
> > iconify-frame is a no-op for TTY frames?
>
> Martin mentioned in passing that he thinks iconifying frames on ttys
> should perhaps do something. So it's maybe a "not yet".
What could that "something" possibly be? Martin?
> > More importantly, what frames could have this function return nil?
> > E.g., can a non-child frame return nil?
>
> Yes. C-x 5 2 can make a new root frame, and only one is visible on
> the display.
So only the top root frame now returns visible = t?
> > Also, what do make-frame-visible and raise-frame do with TTY frames
> > for which frame-visible-p returns nil, and what does
> > make-frame-invisible do for those TTY frames for which this function
> > returns non-nil?
>
> raise-frame is make-frame-visible + changing z-order, make-frame-visible
> and make-frame-invisible change the "visible" flag. (Just notices
> make-frame-visible talks about "X window", hm.).
>
> Did you mean these doc strings should be changed, too, or did you mean
> something else?
I wanted first to understand what happens with this on TTY frames.
Then we'd need to update the doc strings and also the manuals.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 08:13:02 GMT)
Full text and
rfc822 format available.
Message #152 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> Date: Sun, 26 Jan 2025 08:50:14 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > What happens in this case is that F2 cannot be communicated with:
> > typing anything there gets no response, until we exit the minibuffer
> > on F1. Then everything you typed on F2 gets processed.
> >
> >> Find in the code what actually happens when switching from F1 to F2 and
> >> compare that with admin/notes/multi-tty has to say about that. Does that
> >> document say something about what we've seen the code doing? Open issues
> >> maybe? Or general considerations?
> >
> > What the code does when Emacs enters a minibuffer is switch to a
> > "single-keyboard mode", whereby it only processes keyboard input from
> > the frame which entered the minibuffer. This is because Emacs has
> > only one input queue.
>
> I would perhaps check how that switching to single-kboard is done. That
> is, which C functions do that, what does do_switch_frame do and so on.
See temporarily_switch_to_single_kboard in keyboard.c.
> And why does the mini_frame in redisplay_internal end up invisible? Is
> F1 invisible now, and if so why?
I don't think I follow: what mini_frame are you talking about? AFAIU,
the scenario described in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75056#92
said that the child frame (which is the minibuffer frame in this
scenario, right?) was dismissed, so the fact that it becomes invisible
is explained by that? Or maybe I didn't understand what was described
there, since, unfortunately, this uses Corfu without telling enough
about what's going on for people who are unfamiliar with Corfu.
AFAIU, the scenario described there was talking about child frames,
and the problem was that the child frame got displayed although it was
dismissed before.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 08:13:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Yes. C-x 5 2 can make a new root frame, and only one is visible on
>> the display.
>
> So only the top root frame now returns visible = t?
Yes.
(Where "top" in that case is not a z-order thing, but all root frames on
a tty are just part of the frame lists in parallel to each other, like
before child frames. AFAIR, something in tty_display_info
says who owns the terminal.)
...
>> Did you mean these doc strings should be changed, too, or did you mean
>> something else?
>
> I wanted first to understand what happens with this on TTY frames.
> Then we'd need to update the doc strings and also the manuals.
Okay. Maybe we should wait a bit to see how far Martin goes. AFAIU,
minibuffer-only child frames are possible now, for example.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 08:30:02 GMT)
Full text and
rfc822 format available.
Message #158 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: martin rudalics <rudalics <at> gmx.at>, lenbok <at> gmail.com,
> 75056 <at> debbugs.gnu.org
> Date: Sun, 26 Jan 2025 09:12:17 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> Yes. C-x 5 2 can make a new root frame, and only one is visible on
> >> the display.
> >
> > So only the top root frame now returns visible = t?
>
> Yes.
>
> (Where "top" in that case is not a z-order thing, but all root frames on
> a tty are just part of the frame lists in parallel to each other, like
> before child frames. AFAIR, something in tty_display_info
> says who owns the terminal.)
So it is still true that a frame other than the top frame returns t
from frame-visible-p, right? Here's the recipe:
emacs -Q -nw
C-x 5 b RET
M-: (frame-visible-p (next-frame)) RET
=> t
This is different from GUI frames, in that z-order is not considered
on TTYs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 08:42:02 GMT)
Full text and
rfc822 format available.
Message #161 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> I would perhaps check how that switching to single-kboard is done. That
>> is, which C functions do that, what does do_switch_frame do and so on.
>
> See temporarily_switch_to_single_kboard in keyboard.c.
After reading admin/notes/multi-tty, I don't want to go down that rabbit
hole :-).
>
>> And why does the mini_frame in redisplay_internal end up invisible? Is
>> F1 invisible now, and if so why?
>
> I don't think I follow: what mini_frame are you talking about? AFAIU,
> the scenario described in
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75056#92
>
> said that the child frame (which is the minibuffer frame in this
> scenario, right?) was dismissed, so the fact that it becomes invisible
> is explained by that?
(In message #77 I mention the mini_frame in redisplay_internal which was
invisible for some reason, and that led to a crash in
combine_updates_for_frame.)
In #92 I think Len means disappeared from the screen. As far as I know,
if Len is using Vertico-Posframe, this means the Posframe child frame
has been made invisible (not deleted).
Everything normal up to this point.
Then he switches to the other frame and strange things happen.
Apparently someone somewhere gets confused. The Posframe that was just
made invisible is made visible (why?) and the mini_frame was invisible
(why?), although in another case.
From what I've read so far, I can't explain that. That's why I came up
with my description of how I would try to understand this, without child
frames first. (I don't want to debug this, sorry.)
> Or maybe I didn't understand what was described there, since,
> unfortunately, this uses Corfu without telling enough about what's
> going on for people who are unfamiliar with Corfu. AFAIU, the scenario
> described there was talking about child frames, and the problem was
> that the child frame got displayed although it was dismissed before.
It's Posframe. It does things to display the minibuffer in a child
frame. without having a minibuffer. Also involved is Vertico which is a
completion framework that also does complicated things.
As I said, I would start to try understanding this from the ground up,
and add the complicated stuff step by step. First without anything, then
add Vertico, then add Posframe.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 08:54:02 GMT)
Full text and
rfc822 format available.
Message #164 received at 75056 <at> debbugs.gnu.org (full text, mbox):
>> Martin mentioned in passing that he thinks iconifying frames on ttys
>> should perhaps do something. So it's maybe a "not yet".
>
> What could that "something" possibly be? Martin?
See the option 'iconify-child-frame'. We have to explain its semantics
for tty child frames: The two obvious choices are to either do nothing
or make the child frame invisible.
>> Yes. C-x 5 2 can make a new root frame, and only one is visible on
>> the display.
>
> So only the top root frame now returns visible = t?
What is the "top root frame"? Have we defined it somewhere?
>> raise-frame is make-frame-visible + changing z-order, make-frame-visible
>> and make-frame-invisible change the "visible" flag. (Just notices
>> make-frame-visible talks about "X window", hm.).
>>
>> Did you mean these doc strings should be changed, too, or did you mean
>> something else?
>
> I wanted first to understand what happens with this on TTY frames.
> Then we'd need to update the doc strings and also the manuals.
I still wonder what happened to the "when one frame completely obscures
another" visibility state issue. Has that vanished? IIUC it would make
a child frame (and possible even a root frame) practically invisible
when no part of its drawn by redisplay. On a GUI the WM would decide
that and we don't have to care (IIRC we did care on Windows in the past
- at least when debugging).
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 08:56:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> (Where "top" in that case is not a z-order thing, but all root frames on
>> a tty are just part of the frame lists in parallel to each other, like
>> before child frames. AFAIR, something in tty_display_info
>> says who owns the terminal.)
>
> So it is still true that a frame other than the top frame returns t
> from frame-visible-p, right? Here's the recipe:
>
> emacs -Q -nw
> C-x 5 b RET
> M-: (frame-visible-p (next-frame)) RET
> => t
>
> This is different from GUI frames, in that z-order is not considered
> on TTYs.
That looks like a bug to me. I think it should return nil. (Although I'm
never 100% sure with the frame code.) Opinions?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 09:01:01 GMT)
Full text and
rfc822 format available.
Message #170 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> Cc: lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> Date: Sun, 26 Jan 2025 10:11:50 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> > Cc: lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> > Date: Sun, 26 Jan 2025 08:50:14 +0100
> >
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> > > What happens in this case is that F2 cannot be communicated with:
> > > typing anything there gets no response, until we exit the minibuffer
> > > on F1. Then everything you typed on F2 gets processed.
> > >
> > >> Find in the code what actually happens when switching from F1 to F2 and
> > >> compare that with admin/notes/multi-tty has to say about that. Does that
> > >> document say something about what we've seen the code doing? Open issues
> > >> maybe? Or general considerations?
> > >
> > > What the code does when Emacs enters a minibuffer is switch to a
> > > "single-keyboard mode", whereby it only processes keyboard input from
> > > the frame which entered the minibuffer. This is because Emacs has
> > > only one input queue.
> >
> > I would perhaps check how that switching to single-kboard is done. That
> > is, which C functions do that, what does do_switch_frame do and so on.
>
> See temporarily_switch_to_single_kboard in keyboard.c.
Btw, when I do that on the current master branch, I see some
unexplained cursor movements. Recipe:
$ emacs -Q -nw
M-x server-start RET
Now on another TTY display:
$ ./lib/src/emacsclient -t ./src/dispnew.c
Now observe how the cursor on the first display (where we started
"emacs -Q -nw") is positioned at the left edge of the mode line,
instead of keeping its previous position.
Now switch back to the fist TTY display and press some key. The
cursor is moved to its correct position, but now the cursor on the
second TTY display is a the beginning of the mini-window!
Now switch to the second TTY display and press down-arrow: the cursor
on that display is now correct, but the cursor on the first display is
now at the beginning of the mini-window.
Here's another problem with cursor movement, which doesn't involve
multy-tty at all:
$ emacs -Q -nw
C-x 5 b RET
M-: (frame-visible-p (next-frame))
After typing the last line above into the minibuffer, don't press RET.
Instead, move the cursor left one character with C-b and type "C-x
C-e". This should evaluate the (next-frame) part and show the result
in the echo-area. But note that, while showing the result of the
evaluation, the cursor is not at the end of the value returned by
next-frame, but several places to the right, after some empty space.
This doesn't happen in Emacs 30.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 09:11:02 GMT)
Full text and
rfc822 format available.
Message #173 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 26 Jan 2025 09:53:19 +0100
> Cc: lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
>
> >> Martin mentioned in passing that he thinks iconifying frames on ttys
> >> should perhaps do something. So it's maybe a "not yet".
> >
> > What could that "something" possibly be? Martin?
>
> See the option 'iconify-child-frame'. We have to explain its semantics
> for tty child frames: The two obvious choices are to either do nothing
> or make the child frame invisible.
OK, but then this is only relevant to child frames on a TTY.
> >> Yes. C-x 5 2 can make a new root frame, and only one is visible on
> >> the display.
> >
> > So only the top root frame now returns visible = t?
>
> What is the "top root frame"? Have we defined it somewhere?
See tty-top-frame.
> >> raise-frame is make-frame-visible + changing z-order, make-frame-visible
> >> and make-frame-invisible change the "visible" flag. (Just notices
> >> make-frame-visible talks about "X window", hm.).
> >>
> >> Did you mean these doc strings should be changed, too, or did you mean
> >> something else?
> >
> > I wanted first to understand what happens with this on TTY frames.
> > Then we'd need to update the doc strings and also the manuals.
>
> I still wonder what happened to the "when one frame completely obscures
> another" visibility state issue. Has that vanished?
No, we still ignore that on TTYs, for non-child frames. See my other
message.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 09:11:02 GMT)
Full text and
rfc822 format available.
Message #176 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> I still wonder what happened to the "when one frame completely obscures
> another" visibility state issue. Has that vanished? IIUC it would make
> a child frame (and possible even a root frame) practically invisible
> when no part of its drawn by redisplay. On a GUI the WM would decide
> that and we don't have to care (IIRC we did care on Windows in the past
> - at least when debugging).
I can't claim that I understand completely what the problem was/is, but
here is the situation on ttys:
On ttys, child frames which are invisible are not copied to the frame's
desired matrix, so they disappear. If children are obscured by others
is handled by copying in reverse z-order, from bottom to top. No
smartness invested in determining if we can avoid copying a child
because it is obscured by another.
Above combine_updates, in the glyph generating code, child frames are
handled completely independent of each other, as if they were the sole
frame on their own terminals. So no obscuring, nothing of that sort.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 09:14:02 GMT)
Full text and
rfc822 format available.
Message #179 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: rudalics <at> gmx.at, lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> Date: Sun, 26 Jan 2025 09:55:48 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> (Where "top" in that case is not a z-order thing, but all root frames on
> >> a tty are just part of the frame lists in parallel to each other, like
> >> before child frames. AFAIR, something in tty_display_info
> >> says who owns the terminal.)
> >
> > So it is still true that a frame other than the top frame returns t
> > from frame-visible-p, right? Here's the recipe:
> >
> > emacs -Q -nw
> > C-x 5 b RET
> > M-: (frame-visible-p (next-frame)) RET
> > => t
> >
> > This is different from GUI frames, in that z-order is not considered
> > on TTYs.
>
> That looks like a bug to me. I think it should return nil. (Although I'm
> never 100% sure with the frame code.) Opinions?
It's the way Emacs behaved until now with TTY frames. We can decide
we want to change that in Emacs 31, of course, but then we need to
update the documentation accordingly. E.g., see "Raising and
Lowering" in the ELisp manual, and the functions mentioned there.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 09:14:03 GMT)
Full text and
rfc822 format available.
Message #182 received at 75056 <at> debbugs.gnu.org (full text, mbox):
>> So it is still true that a frame other than the top frame returns t
>> from frame-visible-p, right? Here's the recipe:
>>
>> emacs -Q -nw
>> C-x 5 b RET
>> M-: (frame-visible-p (next-frame)) RET
>> => t
>>
>> This is different from GUI frames, in that z-order is not considered
>> on TTYs.
>
> That looks like a bug to me. I think it should return nil. (Although I'm
> never 100% sure with the frame code.) Opinions?
The doc-string of 'make-frame-invisible' says that
This function has no effect on text terminal frames. Such frames are
always considered visible, whether or not they are currently being
displayed in the terminal.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 09:20:01 GMT)
Full text and
rfc822 format available.
Message #185 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>>> So it is still true that a frame other than the top frame returns t
>>> from frame-visible-p, right? Here's the recipe:
>>>
>>> emacs -Q -nw
>>> C-x 5 b RET
>>> M-: (frame-visible-p (next-frame)) RET
>>> => t
>>>
>>> This is different from GUI frames, in that z-order is not considered
>>> on TTYs.
>>
>> That looks like a bug to me. I think it should return nil. (Although I'm
>> never 100% sure with the frame code.) Opinions?
>
> The doc-string of 'make-frame-invisible' says that
>
> This function has no effect on text terminal frames. Such frames are
> always considered visible, whether or not they are currently being
> displayed in the terminal.
>
> martin
Should we make a bug for that so that is doesn't get forgotten?
Probably also a lot of other doc strings need fixing. make-frame-visible
is also not right. And another one I changed recently.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 09:25:01 GMT)
Full text and
rfc822 format available.
Message #188 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: rudalics <at> gmx.at, lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
>> Date: Sun, 26 Jan 2025 09:55:48 +0100
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> (Where "top" in that case is not a z-order thing, but all root frames on
>> >> a tty are just part of the frame lists in parallel to each other, like
>> >> before child frames. AFAIR, something in tty_display_info
>> >> says who owns the terminal.)
>> >
>> > So it is still true that a frame other than the top frame returns t
>> > from frame-visible-p, right? Here's the recipe:
>> >
>> > emacs -Q -nw
>> > C-x 5 b RET
>> > M-: (frame-visible-p (next-frame)) RET
>> > => t
>> >
>> > This is different from GUI frames, in that z-order is not considered
>> > on TTYs.
>>
>> That looks like a bug to me. I think it should return nil. (Although I'm
>> never 100% sure with the frame code.) Opinions?
>
> It's the way Emacs behaved until now with TTY frames. We can decide
> we want to change that in Emacs 31, of course, but then we need to
> update the documentation accordingly. E.g., see "Raising and
> Lowering" in the ELisp manual, and the functions mentioned there.
I'd vote for changing this. I find things easier to understand when
there are as few as possible exceptions.
BTW, what does (frame-visible-p F) say, when F is a frame on another
terminal? Out of interest. I would find it natural if that returned t
if F is the top frame of that terminal, and nil if not.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 09:39:01 GMT)
Full text and
rfc822 format available.
Message #191 received at 75056 <at> debbugs.gnu.org (full text, mbox):
>> >> Martin mentioned in passing that he thinks iconifying frames on ttys
>> >> should perhaps do something. So it's maybe a "not yet".
>> >
>> > What could that "something" possibly be? Martin?
>>
>> See the option 'iconify-child-frame'. We have to explain its semantics
>> for tty child frames: The two obvious choices are to either do nothing
>> or make the child frame invisible.
>
> OK, but then this is only relevant to child frames on a TTY.
Yes.
>> What is the "top root frame"? Have we defined it somewhere?
>
> See tty-top-frame.
So it has nothing to do with "root" frames. BTW this apparently changed
now. If in the currently visible frame I do
(tty-top-frame) -> F1
(make-frame) -> F2
(tty-top-frame) -> F1
(previous-frame) -> F2
(raise-frame (previous-frame)) -> F2
(tty-top-frame) -> F1
What I see is F2.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 09:41:02 GMT)
Full text and
rfc822 format available.
Message #194 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Btw, when I do that on the current master branch, I see some
> unexplained cursor movements. Recipe:
>
> $ emacs -Q -nw
> M-x server-start RET
>
> Now on another TTY display:
>
> $ ./lib/src/emacsclient -t ./src/dispnew.c
>
> Now observe how the cursor on the first display (where we started
> "emacs -Q -nw") is positioned at the left edge of the mode line,
> instead of keeping its previous position.
>
> Now switch back to the fist TTY display and press some key. The
> cursor is moved to its correct position, but now the cursor on the
> second TTY display is a the beginning of the mini-window!
>
> Now switch to the second TTY display and press down-arrow: the cursor
> on that display is now correct, but the cursor on the first display is
> now at the beginning of the mini-window.
Can you please submit a bug for this? I'm forgetting things.
> Here's another problem with cursor movement, which doesn't involve
> multy-tty at all:
>
> $ emacs -Q -nw
> C-x 5 b RET
> M-: (frame-visible-p (next-frame))
>
> After typing the last line above into the minibuffer, don't press RET.
> Instead, move the cursor left one character with C-b and type "C-x
> C-e". This should evaluate the (next-frame) part and show the result
> in the echo-area. But note that, while showing the result of the
> evaluation, the cursor is not at the end of the value returned by
> next-frame, but several places to the right, after some empty space.
> This doesn't happen in Emacs 30.
Not sure, but I think this could be explained by frame-visible-p of
other non-top root frames returning t.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 10:07:02 GMT)
Full text and
rfc822 format available.
Message #197 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 26 Jan 2025 10:38:44 +0100
> Cc: gerd.moellmann <at> gmail.com, lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
>
> >> What is the "top root frame"? Have we defined it somewhere?
> >
> > See tty-top-frame.
>
> So it has nothing to do with "root" frames. BTW this apparently changed
> now. If in the currently visible frame I do
>
> (tty-top-frame) -> F1
> (make-frame) -> F2
> (tty-top-frame) -> F1
> (previous-frame) -> F2
> (raise-frame (previous-frame)) -> F2
> (tty-top-frame) -> F1
>
> What I see is F2.
Sounds like a bug. Works as expected in Emacs 30.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 10:15:02 GMT)
Full text and
rfc822 format available.
Message #200 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> Date: Sun, 26 Jan 2025 10:40:33 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Btw, when I do that on the current master branch, I see some
> > unexplained cursor movements. Recipe:
> >
> > $ emacs -Q -nw
> > M-x server-start RET
> >
> > Now on another TTY display:
> >
> > $ ./lib/src/emacsclient -t ./src/dispnew.c
> >
> > Now observe how the cursor on the first display (where we started
> > "emacs -Q -nw") is positioned at the left edge of the mode line,
> > instead of keeping its previous position.
> >
> > Now switch back to the fist TTY display and press some key. The
> > cursor is moved to its correct position, but now the cursor on the
> > second TTY display is a the beginning of the mini-window!
> >
> > Now switch to the second TTY display and press down-arrow: the cursor
> > on that display is now correct, but the cursor on the first display is
> > now at the beginning of the mini-window.
>
> Can you please submit a bug for this? I'm forgetting things.
Done (two bug reports about two problems, not sure they are the same
problem).
> > Here's another problem with cursor movement, which doesn't involve
> > multy-tty at all:
> >
> > $ emacs -Q -nw
> > C-x 5 b RET
> > M-: (frame-visible-p (next-frame))
> >
> > After typing the last line above into the minibuffer, don't press RET.
> > Instead, move the cursor left one character with C-b and type "C-x
> > C-e". This should evaluate the (next-frame) part and show the result
> > in the echo-area. But note that, while showing the result of the
> > evaluation, the cursor is not at the end of the value returned by
> > next-frame, but several places to the right, after some empty space.
> > This doesn't happen in Emacs 30.
>
> Not sure, but I think this could be explained by frame-visible-p of
> other non-top root frames returning t.
I meant only the incorrect cursor position. That's the second bug I
submitted.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 10:38:01 GMT)
Full text and
rfc822 format available.
Message #203 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Can you please submit a bug for this? I'm forgetting things.
>
> Done (two bug reports about two problems, not sure they are the same
> problem).
Thanks!
>> Not sure, but I think this could be explained by frame-visible-p of
>> other non-top root frames returning t.
>
> I meant only the incorrect cursor position. That's the second bug I
> submitted.
Okay, thanks!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 11:06:02 GMT)
Full text and
rfc822 format available.
Message #206 received at 75056 <at> debbugs.gnu.org (full text, mbox):
>> I still wonder what happened to the "when one frame completely obscures
>> another" visibility state issue. Has that vanished?
>
> No, we still ignore that on TTYs, for non-child frames. See my other
> message.
Are you sure? frame.h now has
/* Nonzero if the frame is currently displayed; we check
it to see if we should bother updating the frame's contents. */
unsigned visible : 1;
where it formerly had
/* Nonzero if the frame is currently displayed; we check
it to see if we should bother updating the frame's contents.
On ttys and on Windows NT/9X, to avoid wasting effort updating
visible frames that are actually completely obscured by other
windows on the display, we bend the meaning of visible slightly:
if equal to 2, then the frame is obscured - we still consider
it to be "visible" as seen from lisp, but we don't bother
updating it. */
unsigned visible : 2;
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 11:24:01 GMT)
Full text and
rfc822 format available.
Message #209 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 26 Jan 2025 12:04:56 +0100
> Cc: gerd.moellmann <at> gmail.com, lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
>
> >> I still wonder what happened to the "when one frame completely obscures
> >> another" visibility state issue. Has that vanished?
> >
> > No, we still ignore that on TTYs, for non-child frames. See my other
> > message.
>
> Are you sure? frame.h now has
>
> /* Nonzero if the frame is currently displayed; we check
> it to see if we should bother updating the frame's contents. */
> unsigned visible : 1;
>
> where it formerly had
>
> /* Nonzero if the frame is currently displayed; we check
> it to see if we should bother updating the frame's contents.
>
> On ttys and on Windows NT/9X, to avoid wasting effort updating
> visible frames that are actually completely obscured by other
> windows on the display, we bend the meaning of visible slightly:
> if equal to 2, then the frame is obscured - we still consider
> it to be "visible" as seen from lisp, but we don't bother
> updating it. */
> unsigned visible : 2;
I just described what factually happens:
emacs -Q -nw
C-x 5 b RET
M-: (frame-visible-p (next-frame)) RET
=> t
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 16:45:02 GMT)
Full text and
rfc822 format available.
Message #212 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> I just described what factually happens:
>
> emacs -Q -nw
> C-x 5 b RET
> M-: (frame-visible-p (next-frame)) RET
> => t
That's what 'frame-visible-p' does. I wondered what happened to
FRAME_OBSCURED_P in w32_read_socket. Has that become obsolete?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 17:20:02 GMT)
Full text and
rfc822 format available.
Message #215 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Can't talk for w32, but I've removed the "obscuring" fromt the ttys because it plainly went against the rest with tty child frames.
> On 26. Jan 2025, at 17:44, martin rudalics <rudalics <at> gmx.at> wrote:
>
> > I just described what factually happens:
> >
> > emacs -Q -nw
> > C-x 5 b RET
> > M-: (frame-visible-p (next-frame)) RET
> > => t
>
> That's what 'frame-visible-p' does. I wondered what happened to
> FRAME_OBSCURED_P in w32_read_socket. Has that become obsolete?
>
> martin
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 26 Jan 2025 19:07:02 GMT)
Full text and
rfc822 format available.
Message #218 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 26 Jan 2025 17:44:39 +0100
> Cc: gerd.moellmann <at> gmail.com, lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
>
> > I just described what factually happens:
> >
> > emacs -Q -nw
> > C-x 5 b RET
> > M-: (frame-visible-p (next-frame)) RET
> > => t
>
> That's what 'frame-visible-p' does. I wondered what happened to
> FRAME_OBSCURED_P in w32_read_socket. Has that become obsolete?
Gerd decided to remove that as part of the TTY child frames changeset.
He said it was an optimization that is not worth keeping.
Why are you asking? did you see any problems caused by that?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Mon, 27 Jan 2025 08:01:01 GMT)
Full text and
rfc822 format available.
Message #221 received at 75056 <at> debbugs.gnu.org (full text, mbox):
(4) As noted elsewhere, the documentation must be rewritten.
> Can't talk for w32, but I've removed the "obscuring" fromt the ttys
> because it plainly went against the rest with tty child frames.
You could have left it in to handle invisible top frames but maybe
that's really not needed any more. Whatever you decide here, the
following issues must be resolved:
(1) Fframe_visible_p has this
else if (is_tty_root_frame (f))
return Qt;
where is_tty_root_frame is defined as
return !FRAME_PARENT_FRAME (f) && is_tty_frame (f);
This is wrong because it will return t even if F has been explicitly
made invisible.
(2) do_switch_frame now has this
if (FRAMEP (top_frame))
{
struct frame *top = XFRAME (top_frame);
struct frame *old_root = root_frame (top);
if (old_root != new_root)
SET_FRAME_VISIBLE (old_root, false);
}
This is wrong because it will set the visibility of the old top frame to
nil. This will change the behavior of many functions that check the
visibility of frames, notably here in candidate_window_p in window.c
else if (EQ (all_frames, Qvisible))
{
candidate_p = FRAME_VISIBLE_P (f)
&& (FRAME_TERMINAL (XFRAME (w->frame))
== FRAME_TERMINAL (XFRAME (selected_frame)));
}
where a window on the prior top frame will be no more considered as
eligible.
(3) I have not checked whether it's needed but I strongly suppose we now
need a frame_visible_invisible_hook for ttys too.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Mon, 27 Jan 2025 08:01:02 GMT)
Full text and
rfc822 format available.
Message #224 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> Gerd decided to remove that as part of the TTY child frames changeset.
> He said it was an optimization that is not worth keeping.
>
> Why are you asking? did you see any problems caused by that?
I wondered whether we did need it on the Windows GUI. Apparently not.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Mon, 27 Jan 2025 19:13:02 GMT)
Full text and
rfc822 format available.
Message #227 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> (4) As noted elsewhere, the documentation must be rewritten.
>
>> Can't talk for w32, but I've removed the "obscuring" fromt the ttys
>> because it plainly went against the rest with tty child frames.
>
> You could have left it in to handle invisible top frames but maybe
> that's really not needed any more. Whatever you decide here, the
> following issues must be resolved:
>
> (1) Fframe_visible_p has this
>
> else if (is_tty_root_frame (f))
> return Qt;
>
> where is_tty_root_frame is defined as
>
> return !FRAME_PARENT_FRAME (f) && is_tty_frame (f);
>
> This is wrong because it will return t even if F has been explicitly
> made invisible.
>
Thanks. That's 100% bug.
> (2) do_switch_frame now has this
>
> if (FRAMEP (top_frame))
> {
> struct frame *top = XFRAME (top_frame);
> struct frame *old_root = root_frame (top);
> if (old_root != new_root)
> SET_FRAME_VISIBLE (old_root, false);
> }
>
> This is wrong because it will set the visibility of the old top frame to
> nil.
I don't understand that one. It doesn't, or shouldn't change, the
visibility of the top_frame, but the visibility of its root. Can you
please explain?
> This will change the behavior of many functions that check the
> visibility of frames, notably here in candidate_window_p in window.c
>
> else if (EQ (all_frames, Qvisible))
> {
> candidate_p = FRAME_VISIBLE_P (f)
> && (FRAME_TERMINAL (XFRAME (w->frame))
> == FRAME_TERMINAL (XFRAME (selected_frame)));
>
> }
Would have to be changed then.
My idea is that root windows on ttys become invisible/invisible when
they are displayed on the terminal or not. Child windows on these roots
keep their visibility. They are automatically not displayed when the
root is not displayed, that's inherently the case when
combine_updates_for frame is not called for invisible root frames.
> where a window on the prior top frame will be no more considered as
> eligible.
>
> (3) I have not checked whether it's needed but I strongly suppose we now
> need a frame_visible_invisible_hook for ttys too.
Okay.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Tue, 28 Jan 2025 09:30:02 GMT)
Full text and
rfc822 format available.
Message #230 received at 75056 <at> debbugs.gnu.org (full text, mbox):
>> (2) do_switch_frame now has this
>>
>> if (FRAMEP (top_frame))
>> {
>> struct frame *top = XFRAME (top_frame);
>> struct frame *old_root = root_frame (top);
>> if (old_root != new_root)
>> SET_FRAME_VISIBLE (old_root, false);
>> }
>>
>> This is wrong because it will set the visibility of the old top frame to
>> nil.
>
> I don't understand that one. It doesn't, or shouldn't change, the
> visibility of the top_frame, but the visibility of its root. Can you
> please explain?
The root_frame of the old top frame is the old top frame itself. Or am
I missing something?
> My idea is that root windows on ttys become invisible/invisible when
> they are displayed on the terminal or not. Child windows on these roots
> keep their visibility. They are automatically not displayed when the
> root is not displayed, that's inherently the case when
> combine_updates_for frame is not called for invisible root frames.
I think we should use the metaphor of a top frame on a tty as that of a
maximized frame on a GUI. Such a frame hides all other normal frames on
that workspace but does not render them invisible or iconified (I ignore
z-order and groups here). If you want to optimize redisplay, then the
old concept of obscured frames will be better suited IMO.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Tue, 28 Jan 2025 10:04:02 GMT)
Full text and
rfc822 format available.
Message #233 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>>> (2) do_switch_frame now has this
>>>
>>> if (FRAMEP (top_frame))
>>> {
>>> struct frame *top = XFRAME (top_frame);
>>> struct frame *old_root = root_frame (top);
>>> if (old_root != new_root)
>>> SET_FRAME_VISIBLE (old_root, false);
>>> }
>>>
>>> This is wrong because it will set the visibility of the old top frame to
>>> nil.
>>
>> I don't understand that one. It doesn't, or shouldn't change, the
>> visibility of the top_frame, but the visibility of its root. Can you
>> please explain?
>
> The root_frame of the old top frame is the old top frame itself. Or am
> I missing something?
Maybe. Make a child with M-l, then in the child
(frame-parent (tty-top-frame)
=> F1
It's 1:1 the display info's top_frame. IOW, I left the setting of
top_frame as is was before, only that there are now child frames to
which it gets set.
>
>> My idea is that root windows on ttys become invisible/invisible when
>> they are displayed on the terminal or not. Child windows on these roots
>> keep their visibility. They are automatically not displayed when the
>> root is not displayed, that's inherently the case when
>> combine_updates_for frame is not called for invisible root frames.
>
> I think we should use the metaphor of a top frame on a tty as that of a
> maximized frame on a GUI. Such a frame hides all other normal frames on
> that workspace but does not render them invisible or iconified (I ignore
> z-order and groups here).
That's not so in the current code. And why should it be so complicated?
Either I can see a frame or not.
> If you want to optimize redisplay, then the old concept of obscured
> frames will be better suited IMO.
It's much easier for me to think about if this second concept of being
obscured does not exist. And it's easier in redisplay: If it's visible
display it, otherwise don't.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Tue, 28 Jan 2025 11:02:01 GMT)
Full text and
rfc822 format available.
Message #236 received at 75056 <at> debbugs.gnu.org (full text, mbox):
>> The root_frame of the old top frame is the old top frame itself. Or am
>> I missing something?
>
> Maybe. Make a child with M-l, then in the child
>
> (frame-parent (tty-top-frame)
> => F1
>
> It's 1:1 the display info's top_frame. IOW, I left the setting of
> top_frame as is was before, only that there are now child frames to
> which it gets set.
What I meant was that currently with
(setq F1 (selected-frame))
(setq F2 (make-frame))
(next-frame)
(frame-visible-p F1)
the last form evaluates to t. But if we change 'frame-visible-p' to not
always return t if the argument frame is a tty frame, the above will
give nil IIUC. And that's not what happens on a GUI.
>> I think we should use the metaphor of a top frame on a tty as that of a
>> maximized frame on a GUI. Such a frame hides all other normal frames on
>> that workspace but does not render them invisible or iconified (I ignore
>> z-order and groups here).
>
> That's not so in the current code. And why should it be so complicated?
> Either I can see a frame or not.
Be aware that it will change the current behavior for top frames and
make tty frame handling different from what it is on a GUI.
> It's much easier for me to think about if this second concept of being
> obscured does not exist. And it's easier in redisplay: If it's visible
> display it, otherwise don't.
The question is not whether to display it if it's not visible. The
question is whether Lisp code should consider it as visible.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Tue, 28 Jan 2025 12:32:01 GMT)
Full text and
rfc822 format available.
Message #239 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>>> The root_frame of the old top frame is the old top frame itself. Or am
>>> I missing something?
>>
>> Maybe. Make a child with M-l, then in the child
>>
>> (frame-parent (tty-top-frame)
>> => F1
>>
>> It's 1:1 the display info's top_frame. IOW, I left the setting of
>> top_frame as is was before, only that there are now child frames to
>> which it gets set.
>
> What I meant was that currently with
>
> (setq F1 (selected-frame))
> (setq F2 (make-frame))
> (next-frame)
> (frame-visible-p F1)
>
> the last form evaluates to t. But if we change 'frame-visible-p' to not
> always return t if the argument frame is a tty frame, the above will
> give nil IIUC. And that's not what happens on a GUI.
>
>>> I think we should use the metaphor of a top frame on a tty as that of a
>>> maximized frame on a GUI. Such a frame hides all other normal frames on
>>> that workspace but does not render them invisible or iconified (I ignore
>>> z-order and groups here).
>>
>> That's not so in the current code. And why should it be so complicated?
>> Either I can see a frame or not.
>
> Be aware that it will change the current behavior for top frames and
> make tty frame handling different from what it is on a GUI.
>
>> It's much easier for me to think about if this second concept of being
>> obscured does not exist. And it's easier in redisplay: If it's visible
>> display it, otherwise don't.
>
> The question is not whether to display it if it's not visible. The
> question is whether Lisp code should consider it as visible.
>
Okay, understood. Changing the C code would be quite a challenge anyway
:-). It took me at least 10x the time to get to what is there now
frame-wise, so to speak, compared to what I needed to add to redisplay.
Will you continue to work on this?
I'm asking because I'm considering to phase down my involvement in
Emacs, at least for some time. I'll continue to be available per mail,
of course, but I don't plan to commit changes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Tue, 28 Jan 2025 17:20:02 GMT)
Full text and
rfc822 format available.
Message #242 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> Okay, understood. Changing the C code would be quite a challenge anyway
> :-). It took me at least 10x the time to get to what is there now
> frame-wise, so to speak, compared to what I needed to add to redisplay.
Don't worry. Nobody really knows what do_switch_frame does but everyone
calls it.
> Will you continue to work on this?
>
> I'm asking because I'm considering to phase down my involvement in
> Emacs, at least for some time. I'll continue to be available per mail,
> of course, but I don't plan to commit changes.
I can try to look into the frame.c related issues. I'm certainly not
able to work on dispnew.c. But maybe it's only the
eassert (FRAME_VISIBLE_P (root));
assertion there that would have to be adapted.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Tue, 28 Jan 2025 17:35:01 GMT)
Full text and
rfc822 format available.
Message #245 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Okay, understood. Changing the C code would be quite a challenge anyway
>> :-). It took me at least 10x the time to get to what is there now
>> frame-wise, so to speak, compared to what I needed to add to redisplay.
>
> Don't worry. Nobody really knows what do_switch_frame does but everyone
> calls it.
:-)
>> Will you continue to work on this?
>>
>> I'm asking because I'm considering to phase down my involvement in
>> Emacs, at least for some time. I'll continue to be available per mail,
>> of course, but I don't plan to commit changes.
>
> I can try to look into the frame.c related issues. I'm certainly not
> able to work on dispnew.c.
Thanks! I can do the redisplay stuff of course, just tell me.
> But maybe it's only the
>
> eassert (FRAME_VISIBLE_P (root));
>
> assertion there that would have to be adapted.
I seem to have missed that, sorry I'm bit distracted ATM. Or was that
the one in combine_updates_for_frame with multi-tty? I think I committed
a workaround/fix for that to master. Also for the root frame always
returning t in frame-visible-p.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Tue, 28 Jan 2025 18:11:02 GMT)
Full text and
rfc822 format available.
Message #248 received at 75056 <at> debbugs.gnu.org (full text, mbox):
>> But maybe it's only the
>>
>> eassert (FRAME_VISIBLE_P (root));
>>
>> assertion there that would have to be adapted.
>
> I seem to have missed that, sorry I'm bit distracted ATM. Or was that
> the one in combine_updates_for_frame with multi-tty? I think I committed
> a workaround/fix for that to master. Also for the root frame always
> returning t in frame-visible-p.
Forget it. I was in the wrong branch. Just to verify one thing: When
in a tty frame I do
(make-frame '((window-system . x)))
move to the graphical and back to the tty frame I get a crash like
#0 terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at ../../src/emacs.c:432
#1 0x000000000069abc9 in die (msg=0x7e0a28 "!FRAME_WINDOW_P (XFRAME (w->frame))", file=0x7e029f "../../src/dispnew.c", line=3193) at ../../src/alloc.c:7989
#2 0x000000000042539b in window_to_frame_hpos (w=0xbcccb98, hpos=0) at ../../src/dispnew.c:3193
#3 0x000000000042b9e5 in tty_set_cursor () at ../../src/dispnew.c:5669
#4 0x000000000042bba5 in write_matrix (f=0xb83fd40, inhibit_id_p=false, set_cursor_p=true, updating_menu_p=false) at ../../src/dispnew.c:5712
#5 0x0000000000427483 in combine_updates_for_frame (f=0xb83fd40, inhibit_scrolling=false) at ../../src/dispnew.c:4012
#6 0x0000000000427622 in combine_updates (roots=XIL(0x7f4b28c21193)) at ../../src/dispnew.c:4052
#7 0x00000000004830cf in redisplay_internal () at ../../src/xdisp.c:17611
#8 0x0000000000480825 in redisplay () at ../../src/xdisp.c:16668
#9 0x00000000005f68ac in read_char (commandflag=1, map=XIL(0x7f4b28c2f623), prev_event=XIL(0), used_mouse_menu=0x7fff72a5a8ef, end_time=0x0) at ../../src/keyboard.c:2672
#10 0x000000000060a7da in read_key_sequence (keybuf=0x7fff72a5aaa0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false, disable_text_conversion_p=false) at ../../src/keyboard.c:10746
#11 0x00000000005f2c2d in command_loop_1 () at ../../src/keyboard.c:1424
#12 0x00000000006d1779 in internal_condition_case (bfun=0x5f27fe <command_loop_1>, handlers=XIL(0x90), hfun=0x5f1c80 <cmd_error>) at ../../src/eval.c:1607
#13 0x00000000005f23c5 in command_loop_2 (handlers=XIL(0x90)) at ../../src/keyboard.c:1163
#14 0x00000000006d0bcf in internal_catch (tag=XIL(0x12390), func=0x5f239b <command_loop_2>, arg=XIL(0x90)) at ../../src/eval.c:1286
#15 0x00000000005f2357 in command_loop () at ../../src/keyboard.c:1141
#16 0x00000000005f1722 in recursive_edit_1 () at ../../src/keyboard.c:749
#17 0x00000000005f194e in Frecursive_edit () at ../../src/keyboard.c:832
#18 0x00000000005ed1ac in main (argc=3, argv=0x7fff72a5b0d8) at ../../src/emacs.c:2628
Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
Any ideas?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Tue, 28 Jan 2025 19:04:02 GMT)
Full text and
rfc822 format available.
Message #251 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>>> But maybe it's only the
>>>
>>> eassert (FRAME_VISIBLE_P (root));
>>>
>>> assertion there that would have to be adapted.
>>
>> I seem to have missed that, sorry I'm bit distracted ATM. Or was that
>> the one in combine_updates_for_frame with multi-tty? I think I committed
>> a workaround/fix for that to master. Also for the root frame always
>> returning t in frame-visible-p.
>
> Forget it. I was in the wrong branch. Just to verify one thing: When
> in a tty frame I do
>
> (make-frame '((window-system . x)))
>
> move to the graphical and back to the tty frame I get a crash like
>
> #0 terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at ../../src/emacs.c:432
> #1 0x000000000069abc9 in die (msg=0x7e0a28 "!FRAME_WINDOW_P (XFRAME
> (w->frame))", file=0x7e029f "../../src/dispnew.c", line=3193) at
> ../../src/alloc.c:7989
> #2 0x000000000042539b in window_to_frame_hpos (w=0xbcccb98, hpos=0) at ../../src/dispnew.c:3193
> #3 0x000000000042b9e5 in tty_set_cursor () at ../../src/dispnew.c:5669
> #4 0x000000000042bba5 in write_matrix (f=0xb83fd40,
> inhibit_id_p=false, set_cursor_p=true, updating_menu_p=false) at
Hm, new fun with multi-tty. I can see the following
We're doing a normal update of a tty root frame. At the end of writing
to the terminal (write_matrix), we try to set the cursor
(tty_set_cursor). tty_set_cursor begins
dispnew.c:
5620 static void
5621 tty_set_cursor (void)
5622 {
5623 struct frame *f = SELECTED_FRAME ();
and further down, when the cursor is not in the echo area, and so on
dispnew.c:
5685 /* We have only one cursor on terminal frames. Use it to
5686 display the cursor of the selected window. */
5687 struct window *w = XWINDOW (FRAME_SELECTED_WINDOW (f));
5688 if (w->cursor.vpos >= 0
5689 /* The cursor vpos may be temporarily out of bounds
5690 in the following situation: There is one window,
5691 with the cursor in the lower half of it. The window
5692 is split, and a message causes a redisplay before
5693 a new cursor position has been computed. */
5694 && w->cursor.vpos < WINDOW_TOTAL_LINES (w))
5695 {
5696 int x = WINDOW_TO_FRAME_HPOS (w, w->cursor.hpos);
5697 int y = WINDOW_TO_FRAME_VPOS (w, w->cursor.vpos);
Means that the selected frame at the time of the update is the X frame.
The redisplay happens from command_loop_1 which tries to get input:
> #8 0x0000000000480825 in redisplay () at ../../src/xdisp.c:16668
> #9 0x00000000005f68ac in read_char (commandflag=1,
> map=XIL(0x7f4b28c2f623), prev_event=XIL(0),
> used_mouse_menu=0x7fff72a5a8ef, end_time=0x0) at
> ../../src/keyboard.c:2672
> #10 0x000000000060a7da in read_key_sequence (keybuf=0x7fff72a5aaa0,
> prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true,
> fix_current_buffer=true, prevent_redisplay=false,
> disable_text_conversion_p=false) at ../../src/keyboard.c:10746
> #11 0x00000000005f2c2d in command_loop_1 () at ../../src/keyboard.c:1424
I would say something in the switching to X and then back to tty is not
working, and the culprit could be do_switch_frame.
But at the same time this would be strange because combine_udpates has
frame.c:
1833 /* After setting `selected_frame`, we're temporarily in an inconsistent
1834 state where (selected-window) != (frame-selected-window). Until this
1835 invariant is restored we should be very careful not to run ELisp code.
1836 (bug#58343) */
1837 selected_frame = frame;
1838
So it should have set the selected_frame to the tty frame. Except when
another switch-frame event or a call to select-frame happens in the
other direction, after a do_switch_frame to the tty frame.
Which is a long way of saying I don't know what's happening.
Maybe you could add "fprintf (stderr" in do_switch_frame in line 1837 so
that one could see if that hypothesis holds water?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Wed, 29 Jan 2025 06:03:02 GMT)
Full text and
rfc822 format available.
Message #254 received at 75056 <at> debbugs.gnu.org (full text, mbox):
>> (make-frame '((window-system . x)))
>>
>> move to the graphical and back to the tty frame I get a crash like
>>
>> #0 terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at ../../src/emacs.c:432
FWIW, I tried the equivalent with (window-system . ns) here, and
couldn't provoke the assertion.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Wed, 29 Jan 2025 07:09:02 GMT)
Full text and
rfc822 format available.
Message #257 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> On 29. Jan 2025, at 07:02, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>
>>> (make-frame '((window-system . x)))
>>>
>>> move to the graphical and back to the tty frame I get a crash like
>>>
>>> #0 terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at ../../src/emacs.c:432
>
> FWIW, I tried the equivalent with (window-system . ns) here, and
> couldn't provoke the assertion.
Correction: I've managed to get one, but I don't know what I did differently.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Wed, 29 Jan 2025 07:50:01 GMT)
Full text and
rfc822 format available.
Message #260 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>> (make-frame '((window-system . x)))
>>>
>>> move to the graphical and back to the tty frame I get a crash like
>>>
>>> #0 terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at ../../src/emacs.c:432
>
> FWIW, I tried the equivalent with (window-system . ns) here, and
> couldn't provoke the assertion.
Using the right worktree helped.
Taking a closer look at tty_set_cursor, using the selected frame here
doesn't make sense to me. I don't see a good reason why the selected
frame has to have anything to do with where to place the cursor in an
updated frame. That looks more like a left-over from times before
multi-tty.
Could you please try the attached, Martin? The first one is what I think
it the fix. The second one is a cleanup that leads to more checks
without having GLYPH_DEBUG. If this also work for you, I'll put that in
master.
(I see a "flicker" of the tty frame after the make-frame. That is also
the case in Emacs 30.)
[0001-Don-t-use-selected-frame-in-tty_set_cursor.patch (text/x-patch, attachment)]
[0002-Replace-two-macros-with-functions-in-dispnew.c.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Wed, 29 Jan 2025 09:07:02 GMT)
Full text and
rfc822 format available.
Message #263 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> Taking a closer look at tty_set_cursor, using the selected frame here
> doesn't make sense to me. I don't see a good reason why the selected
> frame has to have anything to do with where to place the cursor in an
> updated frame. That looks more like a left-over from times before
> multi-tty.
But it seemed to work on the release branch. Anyway, with your patches
I don't see the assertion violation any more so you should check them
in. Maybe you should also adapt the comment
SET_CURSOR_P false means do not set cursor at point in selected window. */
at the beginning of write_matrix.
> Could you please try the attached, Martin? The first one is what I think
> it the fix. The second one is a cleanup that leads to more checks
> without having GLYPH_DEBUG. If this also work for you, I'll put that in
> master.
If my build with GLYPH_DEBUG works, wouldn't it also work without?
> (I see a "flicker" of the tty frame after the make-frame. That is also
> the case in Emacs 30.)
Absolutely no flicker here but the "icon" of the new frame on my
desktop's "tool bar" is blinking and the new frame is not "active" (I
have no idea whatever the equivalents of these on your ns desktop are).
After I click into the new frame the blinking stops. This is distinct
from what happens with 'make-frame' on a GUI frame here, where the new
frame gets input focus and is selected. But it looks to me like a good
solution for the case at hand here.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Wed, 29 Jan 2025 10:20:02 GMT)
Full text and
rfc822 format available.
Message #266 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> But it seemed to work on the release branch. Anyway, with your patches
> I don't see the assertion violation any more so you should check them
> in.
Spoke to early. Now setting the cursor in a C-l child frame doesn't
work any more.
Sorry, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Wed, 29 Jan 2025 12:55:01 GMT)
Full text and
rfc822 format available.
Message #269 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Taking a closer look at tty_set_cursor, using the selected frame here
>> doesn't make sense to me. I don't see a good reason why the selected
>> frame has to have anything to do with where to place the cursor in an
>> updated frame. That looks more like a left-over from times before
>> multi-tty.
>
> But it seemed to work on the release branch. Anyway, with your patches
> I don't see the assertion violation any more so you should check them
> in. Maybe you should also adapt the comment
>
> SET_CURSOR_P false means do not set cursor at point in selected window. */
>
> at the beginning of write_matrix.
I've removed that parameter, see other mail.
>> Could you please try the attached, Martin? The first one is what I think
>> it the fix. The second one is a cleanup that leads to more checks
>> without having GLYPH_DEBUG. If this also work for you, I'll put that in
>> master.
>
> If my build with GLYPH_DEBUG works, wouldn't it also work without?
>
>> (I see a "flicker" of the tty frame after the make-frame. That is also
>> the case in Emacs 30.)
>
> Absolutely no flicker here but the "icon" of the new frame on my
> desktop's "tool bar" is blinking and the new frame is not "active" (I
> have no idea whatever the equivalents of these on your ns desktop are).
> After I click into the new frame the blinking stops. This is distinct
> from what happens with 'make-frame' on a GUI frame here, where the new
> frame gets input focus and is selected. But it looks to me like a good
> solution for the case at hand here.
The flickering looks as if someone calls clear_frame or redraw-frame or
something like that. Maybe Like C-x 5 2 had been called to create
another tty root frame.
Wrt the GUI frame I see nothing unusual. The icon in the dock looks
totally normal, no blinking or anything.
When doing the make-frame, the tty frame first flickers, then the GUI
window opens behind the terminal window. The tty frame stays selected, I
can enter text there and so on.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Wed, 29 Jan 2025 13:05:02 GMT)
Full text and
rfc822 format available.
Message #272 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
martin rudalics <rudalics <at> gmx.at> writes:
>> But it seemed to work on the release branch. Anyway, with your patches
>> I don't see the assertion violation any more so you should check them
>> in.
>
> Spoke to early. Now setting the cursor in a C-l child frame doesn't
> work any more.
Back from the drawing board, please find now 3 patches attached.
Idea was right, only that something was missing: the selected frame is
insofar related to the update that if it is part of the z-order on the
root being updated, it determines which frame in the z-order has the
cursor. Sounds a bit complicated, but fixes the problem :-).
I have rebased to include a comment fix you mentioned in one of the old
commits.
[0001-Don-t-use-selected-frame-in-tty_set_cursor.patch (text/x-patch, attachment)]
[0002-Replace-two-macros-with-functions-in-dispnew.c.patch (text/x-patch, attachment)]
[0003-Further-fixes-for-cursor-positioning.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Wed, 29 Jan 2025 18:04:02 GMT)
Full text and
rfc822 format available.
Message #275 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> Back from the drawing board, please find now 3 patches attached.
Works pretty well so far. I'll do some further experiments with it.
Next question: What is the special purpose of 'tty_child_pos_param'?
With a negative value it makes a frame disappear on the left of the
parent which is not bad per se. But the manual says:
A negative integer relates the right frame edge to the right edge of the
display or parent frame.
So
(modify-frame-parameters nil '((left . -5)))
on a GUI child frame moves the right edge of the child frame by 5 pixels
left of the right edge of the parent. Inherently, negative positions
are deprecated on GUIs.
Also when I want to move a child frame to the left of its parent via
(modify-frame-parameters nil '((left . 0)))
the left border disappears. Is that intended?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Wed, 29 Jan 2025 19:10:02 GMT)
Full text and
rfc822 format available.
Message #278 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Back from the drawing board, please find now 3 patches attached.
>
> Works pretty well so far. I'll do some further experiments with it.
Thanks!
> Next question: What is the special purpose of 'tty_child_pos_param'?
> With a negative value it makes a frame disappear on the left of the
> parent which is not bad per se. But the manual says:
>
> A negative integer relates the right frame edge to the right edge of the
> display or parent frame.
>
> So
>
> (modify-frame-parameters nil '((left . -5)))
>
> on a GUI child frame moves the right edge of the child frame by 5 pixels
> left of the right edge of the parent. Inherently, negative positions
> are deprecated on GUIs.
You mean this one (nice copy function I pilfered from the Internetz):
frame.c:
1451 int
1452 tty_child_pos_param (struct frame *child, Lisp_Object key,
1453 Lisp_Object params, int dflt)
1454 {
1455 Lisp_Object val = Fassq (key, params);
1456 if (CONSP (val))
1457 {
1458 val = XCDR (val);
1459 if (FIXNUMP (val))
1460 return XFIXNUM (val);
1461 }
1462 return dflt;
1463 }
1464
It has no inherent special purpose, and probably has a bug as you
describe. Like perhaps the one for the size. Both are an attempt to
mimic what is done for window-system frames, while being depressed that
that cannot be easily reused, and being too lazy to rewrite the whole
frame parameter department :-).
>
> Also when I want to move a child frame to the left of its parent via
>
> (modify-frame-parameters nil '((left . 0)))
>
> the left border disappears. Is that intended?
If I understand that correctly, then probably yes. The borders are drawn
around the frame, so the left border is at left - 1, the right at left +
width + 1, and so on.
Whatever is outside of the terminal is clipped.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Thu, 30 Jan 2025 04:45:02 GMT)
Full text and
rfc822 format available.
Message #281 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Back from the drawing board, please find now 3 patches attached.
>
> Works pretty well so far. I'll do some further experiments with it.
Now pushed to master.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Thu, 30 Jan 2025 05:58:02 GMT)
Full text and
rfc822 format available.
Message #284 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I just rebuilt from master and tested it out with my two tty terminals. We
do still have the original problem where the second tty child frame
reappears when focus is switched to the other terminal, blocking that other
terminal. Given the discussion about cursor setting, note that when the tty
child frame reappears on the deselected terminal, the cursor in the
selected/focused terminal is drawn at the coordinates corresponding to
where the tty child frame is in the deselected terminal (not sure if that
has always been the case).
[image: image.png]
On Thu, 30 Jan 2025 at 17:44, Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:
> martin rudalics <rudalics <at> gmx.at> writes:
>
> >> Back from the drawing board, please find now 3 patches attached.
> >
> > Works pretty well so far. I'll do some further experiments with it.
>
> Now pushed to master.
>
[Message part 2 (text/html, inline)]
[image.png (image/png, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Thu, 30 Jan 2025 07:05:01 GMT)
Full text and
rfc822 format available.
Message #287 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Len Trigg <lenbok <at> gmail.com> writes:
> I just rebuilt from master and tested it out with my two tty terminals. We do still have the original
> problem where the second tty child frame reappears when focus is switched to the other terminal,
> blocking that other terminal. Given the discussion about cursor setting, note that when the tty child
> frame reappears on the deselected terminal, the cursor in the selected/focused terminal is drawn at the
> coordinates corresponding to where the tty child frame is in the deselected terminal (not sure if that
> has always been the case).
Thanks.
I still think this is related to the mini_frame thing we had some days
ago: the mini_frame that was invisible and was displayed nevertheless,
which lead to an assertion with checking enabled, and a SEGV without.
What I added to combined_updates_for_frame must be considered a
workaround to let it not crash. That is lands there with an invisible
frame is the bug that should be investigated.
Nothing for me though, I*m afraid.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Thu, 30 Jan 2025 08:33:02 GMT)
Full text and
rfc822 format available.
Message #290 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> It has no inherent special purpose, and probably has a bug as you
> describe. Like perhaps the one for the size. Both are an attempt to
> mimic what is done for window-system frames, while being depressed that
> that cannot be easily reused, and being too lazy to rewrite the whole
> frame parameter department 🙂.
The position handling is inherently broken on window-system frames too
because we translate negative values to positive ones after the window
manager has processed them. But I'd like to handle values like (+ 10)
to make child frame dragging work so I'll implement that next.
>> Also when I want to move a child frame to the left of its parent via
>>
>> (modify-frame-parameters nil '((left . 0)))
>>
>> the left border disappears. Is that intended?
>
> If I understand that correctly, then probably yes. The borders are drawn
> around the frame, so the left border is at left - 1, the right at left +
> width + 1, and so on.
I see.
> Whatever is outside of the terminal is clipped.
Didn't you once mention that borders can be displayed more nicely? I
obviously forgot how to do that. In either case I'd like to resize
child frames by dragging their borders with the mouse.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Thu, 30 Jan 2025 08:41:02 GMT)
Full text and
rfc822 format available.
Message #293 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> It has no inherent special purpose, and probably has a bug as you
>> describe. Like perhaps the one for the size. Both are an attempt to
>> mimic what is done for window-system frames, while being depressed that
>> that cannot be easily reused, and being too lazy to rewrite the whole
>> frame parameter department 🙂.
>
> The position handling is inherently broken on window-system frames too
> because we translate negative values to positive ones after the window
> manager has processed them. But I'd like to handle values like (+ 10)
> to make child frame dragging work so I'll implement that next.
👍
>
>>> Also when I want to move a child frame to the left of its parent via
>>>
>>> (modify-frame-parameters nil '((left . 0)))
>>>
>>> the left border disappears. Is that intended?
>>
>> If I understand that correctly, then probably yes. The borders are drawn
>> around the frame, so the left border is at left - 1, the right at left +
>> width + 1, and so on.
>
> I see.
>
>> Whatever is outside of the terminal is clipped.
>
> Didn't you once mention that borders can be displayed more nicely? I
> obviously forgot how to do that. In either case I'd like to resize
> child frames by dragging their borders with the mouse.
>
Yes, now even documented:
NEWS:
50 +++
51 ** 'standard-display-table' now has more extra slots.
52 'standard-display-table' has been extended to allow specifying glyphs
53 that are used for borders around child frames and menu separators on TTY
54 frames.
55
56 Call the function 'standard-display-unicode-special-glyphs' to set up
57 the 'standard-display-table's extra slots with Unicode characters.
58 Please see the documentation of that function to see which slots of the
59 display table it changes.
_Much_ nicer than the default IMO. I still wished Emacs would do that by
default, but here were objections.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Thu, 30 Jan 2025 18:01:02 GMT)
Full text and
rfc822 format available.
Message #296 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>>> Also when I want to move a child frame to the left of its parent via
>>>>
>>>> (modify-frame-parameters nil '((left . 0)))
>>>>
>>>> the left border disappears. Is that intended?
>>>
>>> If I understand that correctly, then probably yes. The borders are drawn
>>> around the frame, so the left border is at left - 1, the right at left +
>>> width + 1, and so on.
>>
>> I see.
>>
>>> Whatever is outside of the terminal is clipped.
Troublesome. Please revise that. When I want to resize a child frame
with the mouse, I have to drag its internal border. But as it stands,
the internal border is part of the underlying or root frame and the
whole make_lispy_position mechanism is broken on ttys.
> _Much_ nicer than the default IMO. I still wished Emacs would do that by
> default, but here were objections.
Looks good. But _where_ on earth (that is, in the code) do you that and
how is it related to the width of the internal border?
I attach my latest achievements both in the menu bar and mouse drag
child frame departments. Menu bars now accept navigation with the
keyboard which was pretty non-trivial to do. Mouse dragging works with
header and mode lines - the attached tty-child-frames.el should provide
the necessary ingredients via C-l and M-l.
One bug I noted now is the following. Do C-l and M-l and drag the
yellow and orange frames somehow as in before.png with the cursor in the
yellow frame right before the left edge of the orange frame. Do C-f -
the cursor appears on top of the left edge of the orange frame as in
middle.png. Another C-f moves it into the orange frame as in after.png.
martin
[tty-menubar-and-drag.diff (text/x-patch, attachment)]
[tty-child-frames.el (text/x-emacs-lisp, attachment)]
[before.png (image/png, attachment)]
[middle.png (image/png, attachment)]
[after.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Thu, 30 Jan 2025 18:51:02 GMT)
Full text and
rfc822 format available.
Message #299 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>>>>> Also when I want to move a child frame to the left of its parent via
>>>>>
>>>>> (modify-frame-parameters nil '((left . 0)))
>>>>>
>>>>> the left border disappears. Is that intended?
>>>>
>>>> If I understand that correctly, then probably yes. The borders are drawn
>>>> around the frame, so the left border is at left - 1, the right at left +
>>>> width + 1, and so on.
>>>
>>> I see.
>>>
>>>> Whatever is outside of the terminal is clipped.
>
> Troublesome. Please revise that. When I want to resize a child frame
> with the mouse, I have to drag its internal border. But as it stands,
> the internal border is part of the underlying or root frame and the
> whole make_lispy_position mechanism is broken on ttys.
You drag a child frame with the mouse, what the heck? :-)
There is little chance that I can change how the borders are drawn, I'm
afraid. I started with trying to give tty frames a border_width, and
failed spectacularly. It was so bad that I git reset --hard in a rage,
which is a really rare event.
>> _Much_ nicer than the default IMO. I still wished Emacs would do that by
>> default, but here were objections.
>
> Looks good. But _where_ on earth (that is, in the code) do you that and
> how is it related to the width of the internal border?
See copy_child_glyphs.
dispnew.c:
3729 /* Draw borders around the child frame. */
3730 if (!FRAME_UNDECORATED (child))
3731 {
3732 /* Horizontal line above. */
3733 if (r.y > 0)
3734 produce_box_line (root, child, r.x, r.y - 1, r.w, true);
3735
3736 for (int y = r.y; y < r.y + r.h; ++y)
3737 {
3738 struct glyph_row *root_row = prepare_desired_root_row (root, y);
3739 if (root_row)
3740 produce_box_sides (BOX_VERTICAL, BOX_VERTICAL, root_row, r.x, r.w,
3741 root, child);
3742 }
3743
3744 /* Horizontal line below. */
3745 if (r.y + r.h < root->desired_matrix->matrix_h)
3746 produce_box_line (root, child, r.x, r.y + r.h, r.w, false);
3747 }
The code is not related to an internal border, and I'm relatively sure
tty frames don't have one right now. At least as far as redisplay is
concerned, don't know about the frame parameters/values. It's like for
border_width.
> I attach my latest achievements both in the menu bar and mouse drag
> child frame departments. Menu bars now accept navigation with the
> keyboard which was pretty non-trivial to do. Mouse dragging works with
> header and mode lines - the attached tty-child-frames.el should
> provide the necessary ingredients via C-l and M-l.
👍
> One bug I noted now is the following. Do C-l and M-l and drag the
> yellow and orange frames somehow as in before.png with the cursor in the
> yellow frame right before the left edge of the orange frame. Do C-f -
> the cursor appears on top of the left edge of the orange frame as in
> middle.png. Another C-f moves it into the orange frame as in
> after.png.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Thu, 30 Jan 2025 20:52:02 GMT)
Full text and
rfc822 format available.
Message #302 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
martin rudalics <rudalics <at> gmx.at> writes:
> I attach my latest achievements both in the menu bar and mouse drag
> child frame departments.
Please find a patch attached that makes it build without window-system,
which also shows that internal borders are new in the tty world.
[0001-Make-it-compile-without-window-system.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 31 Jan 2025 03:30:02 GMT)
Full text and
rfc822 format available.
Message #305 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> I attach my latest achievements both in the menu bar and mouse drag
> child frame departments. Menu bars now accept navigation with the
> keyboard which was pretty non-trivial to do. Mouse dragging works with
> header and mode lines - the attached tty-child-frames.el should provide
> the necessary ingredients via C-l and M-l.
Congratulations, impressive! And quite funny to see something like that
on a terminal 😂.
If you are looking for ideas:
Could you make sub-menus display and behave more like on a GUI? For
example, when I choose Tools -> Spell from the menu bar, the Spell menu
replaces the Tools menu on the screen. On a GUI it would display on top
of the parent and one could navigate back to the parent with the mouse.
Similarly for context menus.
Also the first line of the menu "Spell >" looks weird.
And keyboard navigation back from a sub-menu to its parent would be
nice.
Unbelievable 😂 Nice!
Also, moving child frames is pretty nice too!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 31 Jan 2025 08:33:03 GMT)
Full text and
rfc822 format available.
Message #308 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> If you are looking for ideas:
Just came to my mind that one could re-implemented tty menus in Lisp
using child frames.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 31 Jan 2025 09:44:02 GMT)
Full text and
rfc822 format available.
Message #311 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> There is little chance that I can change how the borders are drawn, I'm
> afraid. I started with trying to give tty frames a border_width, and
> failed spectacularly. It was so bad that I git reset --hard in a rage,
> which is a really rare event.
What were the problems?
>> Looks good. But _where_ on earth (that is, in the code) do you that and
>> how is it related to the width of the internal border?
>
> See copy_child_glyphs.
[...]
> The code is not related to an internal border, and I'm relatively sure
> tty frames don't have one right now. At least as far as redisplay is
> concerned, don't know about the frame parameters/values. It's like for
> border_width.
I see. Your approach is simple but relies on the fact that you draw
frames using a painter's algorithm. The decoration of a frame above (in
z-order) obscures the contents (and maybe also decorations) of the
frames beneath.
Basically, what you do is to draw an outer border. For mouse-resizing
frames we can easily expose that outer border to Elisp. But the problem
is with the coordinates. An outer border should belong to its frame and
not the parent. Clicking an outer border with the mouse should activate
its frame and not the parent. We can fix these as well but it will be a
bit contrived.
>> One bug I noted now is the following. Do C-l and M-l and drag the
>> yellow and orange frames somehow as in before.png with the cursor in the
>> yellow frame right before the left edge of the orange frame. Do C-f -
>> the cursor appears on top of the left edge of the orange frame as in
>> middle.png. Another C-f moves it into the orange frame as in
>> after.png.
Note that this is a bug in the cursor setting method. I'm not sure
whether it's been there ever since or was introduced by your recent
changes. In either case, please have a look. You don't need my changes
to reproduce it but it's much easier when you can drag child frames
around.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 31 Jan 2025 09:44:02 GMT)
Full text and
rfc822 format available.
Message #314 received at 75056 <at> debbugs.gnu.org (full text, mbox):
>> I attach my latest achievements both in the menu bar and mouse drag
>> child frame departments.
>
> Please find a patch attached that makes it build without window-system,
> which also shows that internal borders are new in the tty world.
Thanks. I tried my recent changes with a GTK build only so I can check
immediately whether they negatively affect the behavior on the GUI.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 31 Jan 2025 09:45:02 GMT)
Full text and
rfc822 format available.
Message #317 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> Could you make sub-menus display and behave more like on a GUI? For
> example, when I choose Tools -> Spell from the menu bar, the Spell menu
> replaces the Tools menu on the screen. On a GUI it would display on top
> of the parent and one could navigate back to the parent with the mouse.
That would be nice but cascading menus on a tty is non-trivial - there
are already some some very clever hacks to make sure that each menu is
always drawn in its containing frame. BTW, GTK builds can even enlarge
the Emacs frame when the menubar gets longer. Note also that GUI builds
without toolkit cannot cascade menus either.
> Similarly for context menus.
Same difficulties - one might have to move the menu to fit it into its
frame. Not that it cannot be done but on a GUI context menus (or a
tooltip) can be easily drawn outside their owning frame when they get
too large.
> Also the first line of the menu "Spell >" looks weird.
In what sense?
> And keyboard navigation back from a sub-menu to its parent would be
> nice.
Hmm... via backspace?
> Also, moving child frames is pretty nice too!
In particular when debugging child frame behavior.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 31 Jan 2025 09:45:02 GMT)
Full text and
rfc822 format available.
Message #320 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> Just came to my mind that one could re-implemented tty menus in Lisp
> using child frames.
I have never looked into the menu bar drawing code. Does it use a
painter's algorithm?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 31 Jan 2025 10:03:02 GMT)
Full text and
rfc822 format available.
Message #323 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> There is little chance that I can change how the borders are drawn, I'm
>> afraid. I started with trying to give tty frames a border_width, and
>> failed spectacularly. It was so bad that I git reset --hard in a rage,
>> which is a really rare event.
>
> What were the problems?
TTY frames not having borders seems to be an implicit assumption
"everywhere", frame matrix sub-allocation, mouse, menus, you name it.
That was simply too much for me after hours of trying. Maybe someone
else with more patience could try again.
>>> Looks good. But _where_ on earth (that is, in the code) do you that and
>>> how is it related to the width of the internal border?
>>
>> See copy_child_glyphs.
> [...]
>> The code is not related to an internal border, and I'm relatively sure
>> tty frames don't have one right now. At least as far as redisplay is
>> concerned, don't know about the frame parameters/values. It's like for
>> border_width.
>
> I see. Your approach is simple but relies on the fact that you draw
> frames using a painter's algorithm. The decoration of a frame above (in
> z-order) obscures the contents (and maybe also decorations) of the
> frames beneath.
Right. Simple. dumb, good :-)
> Basically, what you do is to draw an outer border.
Yes, I'm playing the window manager.
> For mouse-resizing frames we can easily expose that outer border to
> Elisp. But the problem is with the coordinates. An outer border should
> belong to its frame and not the parent. Clicking an outer border with
> the mouse should activate its frame and not the parent. We can fix
> these as well but it will be a bit contrived.
No comparison with introducing borders for tty frames :-).
>>> One bug I noted now is the following. Do C-l and M-l and drag the
>>> yellow and orange frames somehow as in before.png with the cursor in the
>>> yellow frame right before the left edge of the orange frame. Do C-f -
>>> the cursor appears on top of the left edge of the orange frame as in
>>> middle.png. Another C-f moves it into the orange frame as in
>>> after.png.
>
> Note that this is a bug in the cursor setting method. I'm not sure
> whether it's been there ever since or was introduced by your recent
> changes. In either case, please have a look. You don't need my changes
> to reproduce it but it's much easier when you can drag child frames
> around.
I'll take a look, need to find some time.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 31 Jan 2025 10:06:01 GMT)
Full text and
rfc822 format available.
Message #326 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Could you make sub-menus display and behave more like on a GUI? For
>> example, when I choose Tools -> Spell from the menu bar, the Spell menu
>> replaces the Tools menu on the screen. On a GUI it would display on top
>> of the parent and one could navigate back to the parent with the mouse.
>
> That would be nice but cascading menus on a tty is non-trivial - there
> are already some some very clever hacks to make sure that each menu is
> always drawn in its containing frame. BTW, GTK builds can even enlarge
> the Emacs frame when the menubar gets longer. Note also that GUI builds
> without toolkit cannot cascade menus either.
>
>> Similarly for context menus.
>
> Same difficulties - one might have to move the menu to fit it into its
> frame. Not that it cannot be done but on a GUI context menus (or a
> tooltip) can be easily drawn outside their owning frame when they get
> too large.
>
>> Also the first line of the menu "Spell >" looks weird.
>
> In what sense?
>
>> And keyboard navigation back from a sub-menu to its parent would be
>> nice.
>
> Hmm... via backspace?
I take everything back. I think it would be much much better to do that
all in Lisp.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 31 Jan 2025 10:29:01 GMT)
Full text and
rfc822 format available.
Message #329 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Just came to my mind that one could re-implemented tty menus in Lisp
>> using child frames.
>
> I have never looked into the menu bar drawing code. Does it use a
> painter's algorithm?
The menu bar itself, the stripe at the top of a frame is pretty special.
On GUIs without external, i.e. toolkit, menu bar, a window is used to
display it, on ttys not IIRC. Let's ignore that for a moment.
The menus themselves are drawn, simplifying, in these steps
1. Save away the frame's whole current matrix
2. Produce a desired matrix that contains the menu
3. Update the display. Maybe loop for highlighting item.
4. In the end, restore the display from the current matrix saved in the
first step.
That's save_and_enable_current_matrix, tty_menu_display,
restore_desired_matrix and alike. The event loop is somewhere in
tty_menu_activate IIRC.
I think we could save a lot of complexity with an implementation in
Lisp: Prepare a buffer displaying a menu keymap in a suitable form, with
help-echo, local-map properties and so on, show the buffer in a child
frame, enter an event loop or something and so on.
But it's just an idea I had when thinking of how easy tooltips were to
add in pure Lisp using child frames.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 31 Jan 2025 11:54:02 GMT)
Full text and
rfc822 format available.
Message #332 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 31 Jan 2025 10:44:17 +0100
> Cc: Eli Zaretskii <eliz <at> gnu.org>, lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
>
> > Just came to my mind that one could re-implemented tty menus in Lisp
> > using child frames.
>
> I have never looked into the menu bar drawing code. Does it use a
> painter's algorithm?
What's "a painter's algorithm"?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 31 Jan 2025 12:04:02 GMT)
Full text and
rfc822 format available.
Message #335 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> Date: Fri, 31 Jan 2025 11:28:19 +0100
>
> martin rudalics <rudalics <at> gmx.at> writes:
>
> >> Just came to my mind that one could re-implemented tty menus in Lisp
> >> using child frames.
> >
> > I have never looked into the menu bar drawing code. Does it use a
> > painter's algorithm?
>
> The menu bar itself, the stripe at the top of a frame is pretty special.
> On GUIs without external, i.e. toolkit, menu bar, a window is used to
> display it, on ttys not IIRC.
It's not a window on TTY frames, indeed. See the commentary to
display_menu_bar:
/* Redisplay the menu bar in the frame for window W.
The menu bar of X frames that don't have X toolkit support is
displayed in a special window W->frame->menu_bar_window.
The menu bar of terminal frames is treated specially as far as
glyph matrices are concerned. Menu bar lines are not part of
windows, so the update is done directly on the frame matrix rows
for the menu bar. */
And the corresponding code:
else
#endif /* not USE_X_TOOLKIT and not USE_GTK */
{
/* This is a TTY frame, i.e. character hpos/vpos are used as
pixel x/y. */
init_iterator (&it, w, -1, -1, f->desired_matrix->rows,
MENU_FACE_ID);
it.first_visible_x = 0;
it.last_visible_x = FRAME_COLS (f);
}
> The menus themselves are drawn, simplifying, in these steps
>
> 1. Save away the frame's whole current matrix
>
> 2. Produce a desired matrix that contains the menu
>
> 3. Update the display. Maybe loop for highlighting item.
>
> 4. In the end, restore the display from the current matrix saved in the
> first step.
>
> That's save_and_enable_current_matrix, tty_menu_display,
> restore_desired_matrix and alike. The event loop is somewhere in
> tty_menu_activate IIRC.
Right.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 31 Jan 2025 14:42:01 GMT)
Full text and
rfc822 format available.
Message #338 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> What's "a painter's algorithm"?
I meant what Wikipedia formulates as
The name "painter's algorithm" refers to the technique
employed by many painters where they begin by painting distant parts of
a scene before parts that are nearer, thereby covering some areas of
distant parts.
As for the menu bar it would mean that we draw the (distant) normal
windows first and then cover them with the (nearer) menu bar items.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Fri, 31 Jan 2025 15:15:01 GMT)
Full text and
rfc822 format available.
Message #341 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 31 Jan 2025 15:41:19 +0100
> Cc: gerd.moellmann <at> gmail.com, lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
>
> > What's "a painter's algorithm"?
>
> I meant what Wikipedia formulates as
>
> The name "painter's algorithm" refers to the technique
> employed by many painters where they begin by painting distant parts of
> a scene before parts that are nearer, thereby covering some areas of
> distant parts.
>
> As for the menu bar it would mean that we draw the (distant) normal
> windows first and then cover them with the (nearer) menu bar items.
The TTY menus are drawn by writing the text directly to the desired
matrix, thus overwriting the characters produced from text displayed
in the frame's windows. If that means we are using the painter's
algorithm, then yes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sat, 01 Feb 2025 10:24:01 GMT)
Full text and
rfc822 format available.
Message #344 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> I take everything back. I think it would be much much better to do that
> all in Lisp.
FWIW, a proof-of-concept, only showing a frame with a menu. 200 loc with
half of it copied from tty-tip.el.
[tty-menu.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 02 Feb 2025 04:47:01 GMT)
Full text and
rfc822 format available.
Message #347 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> One bug I noted now is the following. Do C-l and M-l and drag the
> yellow and orange frames somehow as in before.png with the cursor in the
> yellow frame right before the left edge of the orange frame. Do C-f -
> the cursor appears on top of the left edge of the orange frame as in
> middle.png. Another C-f moves it into the orange frame as in after.png.
>
Fix pushed to master.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 02 Feb 2025 08:54:02 GMT)
Full text and
rfc822 format available.
Message #350 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Fix pushed to master.
Confirmed, thanks.
Next issue: Please look at how the mode line of the orange window
overlaps the yellow window in the attached screenshot. It happened
after I mouse-clicked the mode line of the yellow window to bring it to
foreground.
Schon wieder was passiert, martin
[mode-line.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 02 Feb 2025 09:22:01 GMT)
Full text and
rfc822 format available.
Message #353 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Fix pushed to master.
>
> Confirmed, thanks.
>
> Next issue: Please look at how the mode line of the orange window
> overlaps the yellow window in the attached screenshot. It happened
> after I mouse-clicked the mode line of the yellow window to bring it to
> foreground.
>
> Schon wieder was passiert, martin
Okay, pretty strange, I don't have an idea what that could be yet.
I could reproduce it once here, though.
Are the black stripes on the mode-line in your image normal with your
colors? I've changed the colors to while on steingrau and mausgrau
because I was blinded by the bright colors. When I reproduced it, I
could see one mode-line being drawn partially "into" the other child,
but the colors looked okay.
ich wollte doch nur ein bisschen Corfu, mimimi.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 02 Feb 2025 09:44:01 GMT)
Full text and
rfc822 format available.
Message #356 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> Okay, pretty strange, I don't have an idea what that could be yet.
> I could reproduce it once here, though.
I was able to reproduce it once here only. It might be connected to
mouse hovering.
> Are the black stripes on the mode-line in your image normal with your
> colors? I've changed the colors to while on steingrau and mausgrau
> because I was blinded by the bright colors. When I reproduced it, I
> could see one mode-line being drawn partially "into" the other child,
> but the colors looked okay.
IIUC these are the hovering colors for the mouse, I never changed them.
The "All" on the mode line has the final "l" never covered, not even on
GUI frames.
> ich wollte doch nur ein bisschen Corfu, mimimi.
Für Sissy war Korfu immer noch besser als der Genfer See, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 02 Feb 2025 10:09:02 GMT)
Full text and
rfc822 format available.
Message #359 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Okay, pretty strange, I don't have an idea what that could be yet.
>> I could reproduce it once here, though.
>
> I was able to reproduce it once here only. It might be connected to
> mouse hovering.
That was a good clue, it's mouse-highlighting! Move the top-most child
frame so that it obscures a part of the mode-line of the other child
that has mouse-face, then move the mouse into that mode-line part.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 02 Feb 2025 16:14:02 GMT)
Full text and
rfc822 format available.
Message #362 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> The "All" on the mode line has the final "l" never covered, not even on
> GUI frames.
For the "All" not being displayed correctly I've submitted bug#76014.
Seems to be broken in master for a longer time, and before tty child
frames. Maybe the bug rings a bell for someone.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 02 Feb 2025 17:39:02 GMT)
Full text and
rfc822 format available.
Message #365 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Also, moving child frames is pretty nice too!
The attached patch now also resizes child frames by dragging their edges
or corners. One thing that does not work is that when another child
frame is beneath an edge, Emacs selects the child frame beneath the edge
before I can start dragging. I think that frame/child frame selection
with the mouse is not perfect in the current state in three regards:
- When I do down-mouse-1 in the non-selected root frame, Emacs does
'mouse-set-point' there. I think it should do so only for a mouse-1
so I can back out before releasing the mouse button and obviously use
the down-mouse-1 for dragging.
- When I have two overlapping child frames and do down-mouse-1 on a
border of the frame above and that border covers the frame beneath,
Emacs should never select the frame beneath here. Not even after I
release the button.
- Clicking into a child frame anywhere but on a bar does not select it.
This is uncomfortable and at least does not mimic the behavior of GUI
frames on all window managers I know.
I'll look into these tomorrow. Pointers welcome.
martin
[child-frame-menubar-drag-resize.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 02 Feb 2025 19:40:02 GMT)
Full text and
rfc822 format available.
Message #368 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Also, moving child frames is pretty nice too!
>
> The attached patch now also resizes child frames by dragging their edges
> or corners. One thing that does not work is that when another child
> frame is beneath an edge, Emacs selects the child frame beneath the edge
> before I can start dragging. I think that frame/child frame selection
> with the mouse is not perfect in the current state in three regards:
>
> - When I do down-mouse-1 in the non-selected root frame, Emacs does
> 'mouse-set-point' there. I think it should do so only for a mouse-1
> so I can back out before releasing the mouse button and obviously use
> the down-mouse-1 for dragging.
>
> - When I have two overlapping child frames and do down-mouse-1 on a
> border of the frame above and that border covers the frame beneath,
> Emacs should never select the frame beneath here. Not even after I
> release the button.
>
> - Clicking into a child frame anywhere but on a bar does not select it.
> This is uncomfortable and at least does not mimic the behavior of GUI
> frames on all window managers I know.
>
> I'll look into these tomorrow. Pointers welcome.
Thanks!
Works well for me. Only dragging the edges of a child frame doesn't seem
to work like in a GUI.
With the mouse bindings I'm afraid I can't help much. I agree that the
current use of down-mouse-N is generally not such a great idea. Example:
menus on the mode-line. The default binding of down-mouse-1 for opening
the menu is a PITA for trackpad users using tap-to-click, and prevents
keyboard interaction with the menu because lifting the finger closes the
menu.
Likewise, it would be nice if one could drag the child frames without
having to hold the finger pressed on the trackpad. (In contrast to
dragging a region, which can be done with a 3-finger drag.) Very
inconvenient, and a bit inconsistent.
How that all is currently wired is a bit of a mystery to me. There are
a number of keymaps involved, and it is unclear to me which exact
purpose each one has, and where mouse key bindings are exactly put in
and why: input-decode-map, function-key-map, key-translation-map,
global-map, maybe others?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Mon, 03 Feb 2025 05:16:02 GMT)
Full text and
rfc822 format available.
Message #371 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Fix pushed to master.
>
> Confirmed, thanks.
>
> Next issue: Please look at how the mode line of the orange window
> overlaps the yellow window in the attached screenshot. It happened
> after I mouse-clicked the mode line of the yellow window to bring it to
> foreground.
>
> Schon wieder was passiert, martin
Fix pushed to master.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Mon, 03 Feb 2025 08:34:01 GMT)
Full text and
rfc822 format available.
Message #374 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> Fix pushed to master.
Thanks. I won't check it because I probably could not reproduce it
anyway.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 09 Feb 2025 11:02:01 GMT)
Full text and
rfc822 format available.
Message #377 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> I take everything back. I think it would be much much better to do that
>> all in Lisp.
>
> FWIW, a proof-of-concept, only showing a frame with a menu. 200 loc with
> half of it copied from tty-tip.el.
I'm not sure if it's worth it, but I did a bit more. You can try it out
with something like
(tty-menu-popup-menu t menu-bar-file-menu)
[tty-menu.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 09 Feb 2025 11:09:02 GMT)
Full text and
rfc822 format available.
Message #380 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>>> I take everything back. I think it would be much much better to do that
>>> all in Lisp.
>>
>> FWIW, a proof-of-concept, only showing a frame with a menu. 200 loc with
>> half of it copied from tty-tip.el.
>
> I'm not sure if it's worth it, but I did a bit more. You can try it out
> with something like
>
> (tty-menu-popup-menu t menu-bar-file-menu)
Wrong version. Please use this one:
[tty-menu.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 09 Feb 2025 11:28:01 GMT)
Full text and
rfc822 format available.
Message #383 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> Wrong version. Please use this one:
Can you send me one I can load with emacs -Q -nw?
Here it complains about a void defclass.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 09 Feb 2025 11:36:01 GMT)
Full text and
rfc822 format available.
Message #386 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
martin rudalics <rudalics <at> gmx.at> writes:
>> Wrong version. Please use this one:
>
> Can you send me one I can load with emacs -Q -nw?
> Here it complains about a void defclass.
Sorry, I would never have expected that defclass requires eieio, and is
not autoloaded. Sachen gibt's :-/.
[tty-menu.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 09 Feb 2025 15:48:01 GMT)
Full text and
rfc822 format available.
Message #389 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> Sachen gibt's :-/.
Clicking with the mouse on an arbitrary menubar item gets me
Debugger entered--Lisp error: (error "#<frame F1 0x13906d40> is not a valid window")
signal(error ("#<frame F1 0x13906d40> is not a valid window"))
error("%s is not a valid window" #<frame F1 0x13906d40>)
window-normalize-window(#<frame F1 0x13906d40> nil)
window-edges(#<frame F1 0x13906d40> nil t)
(let* ((--cl-rest-- (window-edges win nil t)) (wx (if (= (length --cl-rest--) 4) (car-safe (prog1 --cl-rest-- (setq --cl-rest-- (cdr --cl-rest--)))) (signal 'wrong-number-of-arguments (list '(wx wy _ _) (length --cl-rest--))))) (wy (car-safe (prog1 --cl-rest-- (setq --cl-rest-- (cdr --cl-rest--))))) (_ (car-safe (prog1 --cl-rest-- (setq --cl-rest-- (cdr --cl-rest--))))) (_ (car-safe --cl-rest--))) (list (window-frame win) (+ wx x) (+ wy y)))
(let* ((end (event-end e)) (win (posn-window end)) (x (car (posn-x-y end))) (y (cdr (posn-x-y end)))) (let* ((--cl-rest-- (window-edges win nil t)) (wx (if (= (length --cl-rest--) 4) (car-safe (prog1 --cl-rest-- (setq --cl-rest-- ...))) (signal 'wrong-number-of-arguments (list '... (length --cl-rest--))))) (wy (car-safe (prog1 --cl-rest-- (setq --cl-rest-- (cdr --cl-rest--))))) (_ (car-safe (prog1 --cl-rest-- (setq --cl-rest-- (cdr --cl-rest--))))) (_ (car-safe --cl-rest--))) (list (window-frame win) (+ wx x) (+ wy y))))
(let* ((e d12)) (let* ((end (event-end e)) (win (posn-window end)) (x (car (posn-x-y end))) (y (cdr (posn-x-y end)))) (let* ((--cl-rest-- (window-edges win nil t)) (wx (if (= (length --cl-rest--) 4) (car-safe (prog1 --cl-rest-- ...)) (signal 'wrong-number-of-arguments (list ... ...)))) (wy (car-safe (prog1 --cl-rest-- (setq --cl-rest-- ...)))) (_ (car-safe (prog1 --cl-rest-- (setq --cl-rest-- ...)))) (_ (car-safe --cl-rest--))) (list (window-frame win) (+ wx x) (+ wy y)))))
(if (eventp d12) (let* ((e d12)) (let* ((end (event-end e)) (win (posn-window end)) (x (car (posn-x-y end))) (y (cdr (posn-x-y end)))) (let* ((--cl-rest-- (window-edges win nil t)) (wx (if (= ... 4) (car-safe ...) (signal ... ...))) (wy (car-safe (prog1 --cl-rest-- ...))) (_ (car-safe (prog1 --cl-rest-- ...))) (_ (car-safe --cl-rest--))) (list (window-frame win) (+ wx x) (+ wy y))))) (let ((d11 pos)) (if (and (consp d11) (and (consp (car d11)) (numberp (car (car d11))) (numberp (cdr (car d11)))) (and (consp (cdr d11)) (windowp (car (cdr d11))))) (let* ((win (car (cdr d11))) (y (cdr (car d11))) (x (car (car d11)))) (let* ((--cl-rest-- (window-edges win nil t)) (wx (if ... ... ...)) (wy (car-safe ...)) (_ (car-safe ...)) (_ (car-safe --cl-rest--))) (list (window-frame win) (+ wx x) (+ wy y)))) (let ((d10 pos)) (if (and (consp d10) (and (consp ...) (numberp ...) (consp ...) (numberp ...) (null ...)) (and (consp ...) (framep ...))) (let* ((frame ...) (y ...) (x ...)) (list frame x y)) (let ((d9 pos)) (if (and ... ... ...) (let* ... ...) (let ... ...))))))))
(let ((d12 pos)) (if (eventp d12) (let* ((e d12)) (let* ((end (event-end e)) (win (posn-window end)) (x (car (posn-x-y end))) (y (cdr (posn-x-y end)))) (let* ((--cl-rest-- (window-edges win nil t)) (wx (if ... ... ...)) (wy (car-safe ...)) (_ (car-safe ...)) (_ (car-safe --cl-rest--))) (list (window-frame win) (+ wx x) (+ wy y))))) (let ((d11 pos)) (if (and (consp d11) (and (consp (car d11)) (numberp (car ...)) (numberp (cdr ...))) (and (consp (cdr d11)) (windowp (car ...)))) (let* ((win (car ...)) (y (cdr ...)) (x (car ...))) (let* ((--cl-rest-- ...) (wx ...) (wy ...) (_ ...) (_ ...)) (list (window-frame win) (+ wx x) (+ wy y)))) (let ((d10 pos)) (if (and (consp d10) (and ... ... ... ... ...) (and ... ...)) (let* (... ... ...) (list frame x y)) (let (...) (if ... ... ...))))))))
(if (eq 't d13) (progn (let* ((y (mouse-position)) (frame (if (cdr y) (car-safe (prog1 y ...)) (signal 'wrong-number-of-arguments (list ... ...)))) (x (car-safe (prog1 y (setq y ...))))) (list frame (or x 10) (or y 10)))) (let ((d12 pos)) (if (eventp d12) (let* ((e d12)) (let* ((end (event-end e)) (win (posn-window end)) (x (car ...)) (y (cdr ...))) (let* ((--cl-rest-- ...) (wx ...) (wy ...) (_ ...) (_ ...)) (list (window-frame win) (+ wx x) (+ wy y))))) (let ((d11 pos)) (if (and (consp d11) (and (consp ...) (numberp ...) (numberp ...)) (and (consp ...) (windowp ...))) (let* ((win ...) (y ...) (x ...)) (let* (... ... ... ... ...) (list ... ... ...))) (let ((d10 pos)) (if (and ... ... ...) (let* ... ...) (let ... ...))))))))
(let ((d13 pos)) (if (eq 't d13) (progn (let* ((y (mouse-position)) (frame (if (cdr y) (car-safe ...) (signal ... ...))) (x (car-safe (prog1 y ...)))) (list frame (or x 10) (or y 10)))) (let ((d12 pos)) (if (eventp d12) (let* ((e d12)) (let* ((end ...) (win ...) (x ...) (y ...)) (let* (... ... ... ... ...) (list ... ... ...)))) (let ((d11 pos)) (if (and (consp d11) (and ... ... ...) (and ... ...)) (let* (... ... ...) (let* ... ...)) (let (...) (if ... ... ...))))))))
(if (eq 'nil d14) (progn nil) (let ((d13 pos)) (if (eq 't d13) (progn (let* ((y (mouse-position)) (frame (if ... ... ...)) (x (car-safe ...))) (list frame (or x 10) (or y 10)))) (let ((d12 pos)) (if (eventp d12) (let* ((e d12)) (let* (... ... ... ...) (let* ... ...))) (let ((d11 pos)) (if (and ... ... ...) (let* ... ...) (let ... ...))))))))
(let ((d14 pos)) (if (eq 'nil d14) (progn nil) (let ((d13 pos)) (if (eq 't d13) (progn (let* ((y ...) (frame ...) (x ...)) (list frame (or x 10) (or y 10)))) (let ((d12 pos)) (if (eventp d12) (let* (...) (let* ... ...)) (let (...) (if ... ... ...))))))))
tty-menu-position((buffer (#<frame F1 0x13906d40> (menu-bar) (18 . 0) 0)))
(and t (tty-menu-position position))
(let* ((where (and t (tty-menu-position position)))) (if where (cond ((keymapp menu) (tty-menu-loop menu where)) ((consp menu) (let* ((outer (make-sparse-keymap "outer")) (--cl-var-- menu) (keymap nil) (name nil) (--cl-var-- t)) (while (consp --cl-var--) (setq keymap (car --cl-var--)) (setq name (tty-menu-keymap-name keymap "?")) (define-key outer (vector ...) keymap) (setq --cl-var-- (cdr --cl-var--)) (setq --cl-var-- nil)) (tty-menu-loop outer where) nil)) (t (error "Not a menu: %S" menu)))))
tty-menu-popup-menu((buffer (#<frame F1 0x13906d40> (menu-bar) (18 . 0) 0)) (keymap "Buffers" [("*scratch* " . #f(compiled-function () (interactive nil) #<bytecode -0x16623bd101fe3580>)) ("*Messages* *%" . #f(compiled-function () (interactive nil) #<bytecode -0x16623bd54f393580>))] (command-separator "--") (next-buffer menu-item "Next Buffer" next-buffer :help "Switch to the \"next\" buffer in a cyclic order") (previous-buffer menu-item "Previous Buffer" previous-buffer :help "Switch to the \"previous\" buffer in a cyclic order") (select-named-buffer menu-item "Select Named Buffer..." switch-to-buffer :help "Prompt for a buffer name, and select that buffer in the current window") (list-all-buffers menu-item "List All Buffers" list-buffers :help "Pop up a window listing all Emacs buffers") (select-buffer-in-project menu-item "Select Buffer In Project..." project-switch-to-buffer :help "Prompt for a buffer belonging to current project, and switch to it") (list-buffers-in-project menu-item "List Buffers In Project..." project-list-buffers :help "Pop up a window listing all Emacs buffers belonging to current project")))
apply(tty-menu-popup-menu ((buffer (#<frame F1 0x13906d40> (menu-bar) (18 . 0) 0)) (keymap "Buffers" [("*scratch* " . #f(compiled-function () (interactive nil) #<bytecode -0x16623bd101fe3580>)) ("*Messages* *%" . #f(compiled-function () (interactive nil) #<bytecode -0x16623bd54f393580>))] (command-separator "--") (next-buffer menu-item "Next Buffer" next-buffer :help "Switch to the \"next\" buffer in a cyclic order") (previous-buffer menu-item "Previous Buffer" previous-buffer :help "Switch to the \"previous\" buffer in a cyclic order") (select-named-buffer menu-item "Select Named Buffer..." switch-to-buffer :help "Prompt for a buffer name, and select that buffer in the current window") (list-all-buffers menu-item "List All Buffers" list-buffers :help "Pop up a window listing all Emacs buffers") (select-buffer-in-project menu-item "Select Buffer In Project..." project-switch-to-buffer :help "Prompt for a buffer belonging to current project, and switch to it") (list-buffers-in-project menu-item "List Buffers In Project..." project-list-buffers :help "Pop up a window listing all Emacs buffers belonging to current project"))))
x-popup-menu((buffer (#<frame F1 0x13906d40> (menu-bar) (18 . 0) 0)) (keymap "Buffers" [("*scratch* " . #f(compiled-function () (interactive nil) #<bytecode -0x16623bd101fe3580>)) ("*Messages* *%" . #f(compiled-function () (interactive nil) #<bytecode -0x16623bd54f393580>))] (command-separator "--") (next-buffer menu-item "Next Buffer" next-buffer :help "Switch to the \"next\" buffer in a cyclic order") (previous-buffer menu-item "Previous Buffer" previous-buffer :help "Switch to the \"previous\" buffer in a cyclic order") (select-named-buffer menu-item "Select Named Buffer..." switch-to-buffer :help "Prompt for a buffer name, and select that buffer in the current window") (list-all-buffers menu-item "List All Buffers" list-buffers :help "Pop up a window listing all Emacs buffers") (select-buffer-in-project menu-item "Select Buffer In Project..." project-switch-to-buffer :help "Prompt for a buffer belonging to current project, and switch to it") (list-buffers-in-project menu-item "List Buffers In Project..." project-list-buffers :help "Pop up a window listing all Emacs buffers belonging to current project")))
popup-menu((keymap "Buffers" [("*scratch* " . #f(compiled-function () (interactive nil) #<bytecode -0x16623bd101fe3580>)) ("*Messages* *%" . #f(compiled-function () (interactive nil) #<bytecode -0x16623bd54f393580>))] (command-separator "--") (next-buffer menu-item "Next Buffer" next-buffer :help "Switch to the \"next\" buffer in a cyclic order") (previous-buffer menu-item "Previous Buffer" previous-buffer :help "Switch to the \"previous\" buffer in a cyclic order") (select-named-buffer menu-item "Select Named Buffer..." switch-to-buffer :help "Prompt for a buffer name, and select that buffer in the current window") (list-all-buffers menu-item "List All Buffers" list-buffers :help "Pop up a window listing all Emacs buffers") (select-buffer-in-project menu-item "Select Buffer In Project..." project-switch-to-buffer :help "Prompt for a buffer belonging to current project, and switch to it") (list-buffers-in-project menu-item "List Buffers In Project..." project-list-buffers :help "Pop up a window listing all Emacs buffers belonging to current project")) (#<window 1 on *scratch*> 19 (18 . 0) 0 nil 19 (18 . 0) nil (0 . 0) (1 . 0)) nil t)
menu-bar-open(nil 18)
menu-bar-open-mouse((mouse-1 (nil menu-bar (21 . 0) 2424)))
funcall-interactively(menu-bar-open-mouse (mouse-1 (nil menu-bar (21 . 0) 2424)))
call-interactively(menu-bar-open-mouse nil nil)
command-execute(menu-bar-open-mouse)
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 09 Feb 2025 16:22:01 GMT)
Full text and
rfc822 format available.
Message #392 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Sachen gibt's :-/.
>
> Clicking with the mouse on an arbitrary menubar item gets me
Yeah, I didn't do the integration with the rest of Emacs yet. Looks like
another dark and ancient corner of Emacs. Insofar, please disregard
tty-menu-mode at the moment. But the rest is kind of funny, help-echo,
C-s in menus :-).
Wie auch immer.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 09 Feb 2025 18:11:01 GMT)
Full text and
rfc822 format available.
Message #395 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> martin rudalics <rudalics <at> gmx.at> writes:
>
>>> Sachen gibt's :-/.
>>
>> Clicking with the mouse on an arbitrary menubar item gets me
>
> Yeah, I didn't do the integration with the rest of Emacs yet. Looks like
> another dark and ancient corner of Emacs. Insofar, please disregard
> tty-menu-mode at the moment. But the rest is kind of funny, help-echo,
> C-s in menus :-).
>
> Wie auch immer.
This works better with the menu-bar, although the menu bar itself does
strange stuff while the menu is open. Don't know what that is.
[tty-menu.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Mon, 10 Feb 2025 10:17:01 GMT)
Full text and
rfc822 format available.
Message #398 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> This works better with the menu-bar, although the menu bar itself does
> strange stuff while the menu is open. Don't know what that is.
Still can't test it with emacs -Q -nw
Debugger entered--Lisp error: (void-function cond*)
(cond* ((match* 'nil pos) nil) ((match* 't pos) (let* ((y (mouse-position)) (frame (if (cdr y) (car-safe (prog1 y ...)) (signal 'wrong-number-of-arguments (list ... ...)))) (x (car-safe (prog1 y (setq y ...))))) (list frame (or x 10) (or y 10)))) ((match* (eventp e) pos) (let* ((end (event-end e)) (win (posn-window end)) (x (car (posn-x-y end))) (y (cdr (posn-x-y end)))) (if (windowp win) (let* ((--cl-rest-- (window-edges win nil t)) (wx (if ... ... ...)) (wy (car-safe ...)) (_ (car-safe ...)) (_ (car-safe --cl-rest--))) (list (window-frame win) (+ wx x) (+ wy y))) (let ((menu-bar-lines (frame-parameter win ...))) (list win x (+ y menu-bar-lines)))))) ((match* (cons (cons (numberp x) (numberp y)) (cons (windowp win) _)) pos) (let* ((--cl-rest-- (window-edges win nil t)) (wx (if (= (length --cl-rest--) 4) (car-safe (prog1 --cl-rest-- ...)) (signal 'wrong-number-of-arguments (list ... ...)))) (wy (car-safe (prog1 --cl-rest-- (setq --cl-rest-- ...)))) (_ (car-safe (prog1 --cl-rest-- (setq --cl-rest-- ...)))) (_ (car-safe --cl-rest--))) (list (window-frame win) (+ wx x) (+ wy y)))) ((match* (cons (list (numberp x) (numberp y)) (cons (framep frame) _)) pos) (list frame x y)) ((match* (cons (cons (numberp x) (numberp y)) (cons (framep frame) _)) pos) (list frame x y)) ((match* (cons (numberp x) (numberp y)) pos) (list (selected-frame) x y)) (t (error "%S does not match in tty-menu-position" pos)))
tty-menu-position((tools (#<frame F1 0x21b5cad0> (menu-bar) (26 . 0) 0)))
(and t (tty-menu-position position))
(let* ((where (and t (tty-menu-position position)))) (if where (cond ((keymapp menu) (tty-menu-loop menu where)) ((consp menu) (let* ((outer (make-sparse-keymap "outer")) (--cl-var-- menu) (keymap nil) (name nil) (--cl-var-- t)) (while (consp --cl-var--) (setq keymap (car --cl-var--)) (setq name (tty-menu-keymap-name keymap "?")) (define-key outer (vector ...) keymap) (setq --cl-var-- (cdr --cl-var--)) (setq --cl-var-- nil)) (tty-menu-loop outer where) nil)) (t (error "Not a menu: %S" menu)))))
tty-menu-popup-menu((tools (#<frame F1 0x21b5cad0> (menu-bar) (26 . 0) 0)) (keymap (grep menu-item "Search Files (Grep)..." grep :help "Search files for strings or regexps (with Grep)") (rgrep menu-item "Recursive Grep..." rgrep :help "Interactively ask for parameters and search recursively") (shell-commands menu-item "Shell Commands" (keymap ... ... ... ... ... "Shell Commands")) (compile menu-item "Compile..." compile :help "Invoke compiler or Make in current buffer's directory, view errors") (project-compile menu-item "Compile Project..." project-compile :help "Invoke compiler or Make for current project, view errors") (gdb menu-item "Debugger (GDB)..." gdb :help "Debug a program from within Emacs with GDB") (ede menu-item "Project Support (EDE)" global-ede-mode :help "Toggle the Emacs Development Environment (Global EDE mode)" :button (:toggle bound-and-true-p global-ede-mode)) (project menu-item "Project" (keymap ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... "Project")) (eglot menu-item "Language Server Support (Eglot)" eglot :help "Start language server suitable for this buffer's major-mode") (semantic menu-item "Source Code Parsers (Semantic)" semantic-mode :help "Toggle automatic parsing in source code buffers (Semantic mode)" :button (:toggle bound-and-true-p semantic-mode)) (separator-prog "--") (spell menu-item "Spell Checking" ispell-menu-map) (separator-spell "--") (compare menu-item "Compare (Ediff)" menu-bar-ediff-menu) (ediff-merge menu-item "Merge" menu-bar-ediff-merge-menu) (epatch menu-item "Apply Patch"
menu-bar-epatch-menu) (separator-compare "--") (vc menu-item "Version Control" vc-menu-map :filter vc-menu-map-filter) (separator-vc "--") (gnus menu-item "Read Net News" gnus :help "Read network news groups") (rmail menu-item "Read Mail" menu-bar-read-mail :visible (and read-mail-command ...) :help "Read your mail") (compose-mail menu-item "Compose New Mail" compose-mail :visible (and mail-user-agent ...) :help "Start writing a new mail message") (directory-search menu-item "Directory Servers" eudc-tools-menu) (browse-web menu-item "Browse the Web..." browse-web) (separator-net "--") ...))
apply(tty-menu-popup-menu ((tools (#<frame F1 0x21b5cad0> (menu-bar) (26 . 0) 0)) (keymap (grep menu-item "Search Files (Grep)..." grep :help "Search files for strings or regexps (with Grep)") (rgrep menu-item "Recursive Grep..." rgrep :help "Interactively ask for parameters and search recursively") (shell-commands menu-item "Shell Commands" (keymap ... ... ... ... ... "Shell Commands")) (compile menu-item "Compile..." compile :help "Invoke compiler or Make in current buffer's directory, view errors") (project-compile menu-item "Compile Project..." project-compile :help "Invoke compiler or Make for current project, view errors") (gdb menu-item "Debugger (GDB)..." gdb :help "Debug a program from within Emacs with GDB") (ede menu-item "Project Support (EDE)" global-ede-mode :help "Toggle the Emacs Development Environment (Global EDE mode)" :button (:toggle bound-and-true-p global-ede-mode)) (project menu-item "Project" (keymap ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... "Project")) (eglot menu-item "Language Server Support (Eglot)" eglot :help "Start language server suitable for this buffer's major-mode") (semantic menu-item "Source Code Parsers (Semantic)" semantic-mode :help "Toggle automatic parsing in source code buffers (Semantic mode)" :button (:toggle bound-and-true-p semantic-mode)) (separator-prog "--") (spell menu-item "Spell Checking" ispell-menu-map) (separator-spell "--") (compare menu-item "Compare (Ediff)" menu-bar-ediff-menu) (ediff-merge menu-item "Merge" menu-bar-ediff-merge-menu) (epatch menu-item "Apply Patch"
menu-bar-epatch-menu) (separator-compare "--") (vc menu-item "Version Control" vc-menu-map :filter vc-menu-map-filter) (separator-vc "--") (gnus menu-item "Read Net News" gnus :help "Read network news groups") (rmail menu-item "Read Mail" menu-bar-read-mail :visible (and read-mail-command ...) :help "Read your mail") (compose-mail menu-item "Compose New Mail" compose-mail :visible (and mail-user-agent ...) :help "Start writing a new mail message") (directory-search menu-item "Directory Servers" eudc-tools-menu) (browse-web menu-item "Browse the Web..." browse-web) (separator-net "--") (calendar menu-item "Calendar" calendar :help "Invoke the Emacs built-in calendar") (calc menu-item "Programmable Calculator" calc :help "Invoke the Emacs built-in full scientific calculator") (simple-calculator menu-item "Simple Calculator" calculator :help "Invoke the Emacs built-in quick calculator") (separator-encryption-decryption "--") (encryption-decryption menu-item "Encryption/Decryption" (keymap ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... "Encryption/Decryption")) (separator-games "--") ...)))
x-popup-menu((tools (#<frame F1 0x21b5cad0> (menu-bar) (26 . 0) 0)) (keymap (grep menu-item "Search Files (Grep)..." grep :help "Search files for strings or regexps (with Grep)") (rgrep menu-item "Recursive Grep..." rgrep :help "Interactively ask for parameters and search recursively") (shell-commands menu-item "Shell Commands" (keymap ... ... ... ... ... "Shell Commands")) (compile menu-item "Compile..." compile :help "Invoke compiler or Make in current buffer's directory, view errors") (project-compile menu-item "Compile Project..." project-compile :help "Invoke compiler or Make for current project, view errors") (gdb menu-item "Debugger (GDB)..." gdb :help "Debug a program from within Emacs with GDB") (ede menu-item "Project Support (EDE)" global-ede-mode :help "Toggle the Emacs Development Environment (Global EDE mode)" :button (:toggle bound-and-true-p global-ede-mode)) (project menu-item "Project" (keymap ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... "Project")) (eglot menu-item "Language Server Support (Eglot)" eglot :help "Start language server suitable for this buffer's major-mode") (semantic menu-item "Source Code Parsers (Semantic)" semantic-mode :help "Toggle automatic parsing in source code buffers (Semantic mode)" :button (:toggle bound-and-true-p semantic-mode)) (separator-prog "--") (spell menu-item "Spell Checking" ispell-menu-map) (separator-spell "--") (compare menu-item "Compare (Ediff)" menu-bar-ediff-menu) (ediff-merge menu-item "Merge" menu-bar-ediff-merge-menu) (epatch menu-item "Apply Patch"
menu-bar-epatch-menu) (separator-compare "--") (vc menu-item "Version Control" vc-menu-map :filter vc-menu-map-filter) (separator-vc "--") (gnus menu-item "Read Net News" gnus :help "Read network news groups") (rmail menu-item "Read Mail" menu-bar-read-mail :visible (and read-mail-command ...) :help "Read your mail") (compose-mail menu-item "Compose New Mail" compose-mail :visible (and mail-user-agent ...) :help "Start writing a new mail message") (directory-search menu-item "Directory Servers" eudc-tools-menu) (browse-web menu-item "Browse the Web..." browse-web) (separator-net "--") ...))
popup-menu((keymap (grep menu-item "Search Files (Grep)..." grep :help "Search files for strings or regexps (with Grep)") (rgrep menu-item "Recursive Grep..." rgrep :help "Interactively ask for parameters and search recursively") (shell-commands menu-item "Shell Commands" (keymap ... ... ... ... ... "Shell Commands")) (compile menu-item "Compile..." compile :help "Invoke compiler or Make in current buffer's directory, view errors") (project-compile menu-item "Compile Project..." project-compile :help "Invoke compiler or Make for current project, view errors") (gdb menu-item "Debugger (GDB)..." gdb :help "Debug a program from within Emacs with GDB") (ede menu-item "Project Support (EDE)" global-ede-mode :help "Toggle the Emacs Development Environment (Global EDE mode)" :button (:toggle bound-and-true-p global-ede-mode)) (project menu-item "Project" (keymap ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... "Project")) (eglot menu-item "Language Server Support (Eglot)" eglot :help "Start language server suitable for this buffer's major-mode") (semantic menu-item "Source Code Parsers (Semantic)" semantic-mode :help "Toggle automatic parsing in source code buffers (Semantic mode)" :button (:toggle bound-and-true-p semantic-mode)) (separator-prog "--") (spell menu-item "Spell Checking" ispell-menu-map) (separator-spell "--") (compare menu-item "Compare (Ediff)" menu-bar-ediff-menu) (ediff-merge menu-item "Merge" menu-bar-ediff-merge-menu) (epatch menu-item "Apply Patch" menu-bar-epatch-menu) (separator-compare "--") (vc menu-item "Version
Control" vc-menu-map :filter vc-menu-map-filter) (separator-vc "--") (gnus menu-item "Read Net News" gnus :help "Read network news groups") (rmail menu-item "Read Mail" menu-bar-read-mail :visible (and read-mail-command ...) :help "Read your mail") (compose-mail menu-item "Compose New Mail" compose-mail :visible (and mail-user-agent ...) :help "Start writing a new mail message") (directory-search menu-item "Directory Servers" eudc-tools-menu) (browse-web menu-item "Browse the Web..." browse-web) (separator-net "--") ...) (#<window 1 on *scratch*> 27 (26 . 0) 0 nil 27 (26 . 0) nil (0 . 0) (1 . 0)) nil t)
menu-bar-open(nil 26)
menu-bar-open-mouse((mouse-1 (nil menu-bar (28 . 0) 968)))
funcall-interactively(menu-bar-open-mouse (mouse-1 (nil menu-bar (28 . 0) 968)))
call-interactively(menu-bar-open-mouse nil nil)
command-execute(menu-bar-open-mouse)
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Mon, 10 Feb 2025 13:25:01 GMT)
Full text and
rfc822 format available.
Message #401 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> This works better with the menu-bar, although the menu bar itself does
>> strange stuff while the menu is open. Don't know what that is.
>
> Still can't test it with emacs -Q -nw
>
> Debugger entered--Lisp error: (void-function cond*)
Is that an Emacs <= 30? In master, cond* is fboundp and autoloaded.
BTW, I made a branch here on my side today because things won't work
without a small addition to the C core, a hook that I called
x-popup-menu-function. Reason being that C calls x_popup_menu_1 which is
not exposed to Lisp.
It's still a bit early, I'll holler when I think I have something
more or less usable.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Mon, 10 Feb 2025 15:52:01 GMT)
Full text and
rfc822 format available.
Message #404 received at 75056 <at> debbugs.gnu.org (full text, mbox):
From what I tried so far I can't enter submenus. But the fonts are>> Debugger entered--Lisp error: (void-function cond*)
>
> Is that an Emacs <= 30? In master, cond* is fboundp and autoloaded.
Probably. It doesn't happen any more.
> BTW, I made a branch here on my side today because things won't work
> without a small addition to the C core, a hook that I called
> x-popup-menu-function. Reason being that C calls x_popup_menu_1 which is
> not exposed to Lisp.
>
> It's still a bit early, I'll holler when I think I have something
> more or less usable.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Mon, 10 Feb 2025 17:52:02 GMT)
Full text and
rfc822 format available.
Message #407 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Works well for me. Only dragging the edges of a child frame doesn't seem
> to work like in a GUI.
I think I fixed that now - having coordinates start at 0 and lines and
columns at 1 is a bit hard to grasp. Please have a look.
martin
[child-frame-menubar-drag-resize.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Mon, 10 Feb 2025 19:28:02 GMT)
Full text and
rfc822 format available.
Message #410 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 10 Feb 2025 18:51:09 +0100
> Cc: Eli Zaretskii <eliz <at> gnu.org>, lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
>
> I think I fixed that now - having coordinates start at 0 and lines and
> columns at 1 is a bit hard to grasp. Please have a look.
Columns do start at zero.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Mon, 10 Feb 2025 19:48:01 GMT)
Full text and
rfc822 format available.
Message #413 received at 75056 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> Please have a look.
Works perfectly, thanks!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Mon, 10 Feb 2025 20:09:01 GMT)
Full text and
rfc822 format available.
Message #416 received at 75056 <at> debbugs.gnu.org (full text, mbox):
>> I think I fixed that now - having coordinates start at 0 and lines and
>> columns at 1 is a bit hard to grasp. Please have a look.
>
> Columns do start at zero.
Right. My problem was that the right outer border of a frame which is
80 columns width and whose left outer border is at column -1 and whose
left edge is at column 0 is at column 79 and not at column 80 as I
thought.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sat, 15 Feb 2025 18:21:02 GMT)
Full text and
rfc822 format available.
Message #419 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Works perfectly, thanks!
There's a problem with moving nested child frames out of their child
parents. Load the attached tty-child-frames.el do first M-l and then
C-M-l. You should see a grey child frame embedded in an orange child
frame. Now do
(set-frame-parameter tty-3 'left (- 30))
This gets me
Program received signal SIGSEGV, Segmentation fault.
0x00000000005497d2 in FACE_FROM_ID (f=0xc383e60, id=0) at ../../src/frame.h:1631
1631 eassert (0 <= id && id < FRAME_FACE_CACHE (f)->used);
(gdb) bt
#0 0x00000000005497d2 in FACE_FROM_ID (f=0xc383e60, id=0) at ../../src/frame.h:1631
#1 0x000000000054bc11 in tty_write_glyphs (f=0xc2c9d30, string=0x7fb8f65f86e0, len=71) at ../../src/term.c:793
#2 0x00000000005571c2 in write_glyphs (f=0xc2c9d30, string=0x7fb8f65f84b0, len=71) at ../../src/terminal.c:182
#3 0x000000000042c80b in write_row (f=0xc2c9d30, vpos=12, updating_menu_p=false) at ../../src/dispnew.c:5917
#4 0x000000000042bd05 in write_matrix (f=0xc2c9d30, inhibit_id_p=false, updating_menu_p=false) at ../../src/dispnew.c:5698
#5 0x0000000000427544 in combine_updates_for_frame (f=0xc2c9d30, inhibit_scrolling=false) at ../../src/dispnew.c:4001
#6 0x0000000000427880 in combine_updates (roots=XIL(0x7fb8f3a6a0d3)) at ../../src/dispnew.c:4050
#7 0x0000000000483026 in redisplay_internal () at ../../src/xdisp.c:17613
#8 0x00000000004808db in redisplay () at ../../src/xdisp.c:16670
#9 0x00000000005f6708 in read_char (commandflag=1, map=XIL(0x7fb8f3a6ab83), prev_event=XIL(0), used_mouse_menu=0x7ffd6018477f, end_time=0x0) at ../../src/keyboard.c:2672
#10 0x000000000060a767 in read_key_sequence (keybuf=0x7ffd60184930, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false, disable_text_conversion_p=false) at ../../src/keyboard.c:10757
#11 0x00000000005f2a89 in command_loop_1 () at ../../src/keyboard.c:1424
#12 0x00000000006d02d5 in internal_condition_case (bfun=0x5f265a <command_loop_1>, handlers=XIL(0x90), hfun=0x5f1adc <cmd_error>) at ../../src/eval.c:1602
#13 0x00000000005f2221 in command_loop_2 (handlers=XIL(0x90)) at ../../src/keyboard.c:1163
#14 0x00000000006cf73f in internal_catch (tag=XIL(0x12390), func=0x5f21f7 <command_loop_2>, arg=XIL(0x90)) at ../../src/eval.c:1282
#15 0x00000000005f21b3 in command_loop () at ../../src/keyboard.c:1141
#16 0x00000000005f157e in recursive_edit_1 () at ../../src/keyboard.c:749
#17 0x00000000005f17aa in Frecursive_edit () at ../../src/keyboard.c:832
#18 0x00000000005ecf8c in main (argc=5, argv=0x7ffd60184f68) at ../../src/emacs.c:2558
Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
If you see no simple way to fix this, we can disallow moving child
frames outside their non-root parents. It's a bit inconsistent because
the scenario works on GUIs and it works for tty child frames with a root
parent.
martin
[tty-child-frames.el (text/x-emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Sun, 16 Feb 2025 05:27:02 GMT)
Full text and
rfc822 format available.
Message #422 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On 15. Feb 2025, at 19:20, martin rudalics <rudalics <at> gmx.at> wrote:
>
> > Works perfectly, thanks!
>
> There's a problem with moving nested child frames out of their child
> parents. Load the attached tty-child-frames.el do first M-l and then
> C-M-l. You should see a grey child frame embedded in an orange child
> frame. Now do
>
> (set-frame-parameter tty-3 'left (- 30))
Yep, I can reproduce it.
Could be a problem with copying glyphs from the child to the root's desired matrix because the crash is from invalid glyph contents. When I reproduced it, the glyph in question was completely zeroed, for example.
I've made bug#76321 for this. Can take me a bit to fix, I'm afraid.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Wed, 26 Feb 2025 02:30:02 GMT)
Full text and
rfc822 format available.
Message #425 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I thought I would check in and see if there was any changed behaviour with
respect to this bug, and things seem to be worse if anything.
First up, even just with a single tty emacs (i.e. no emacsclient), the
minibuffer behaviour has changed, so that now it seems the minibuffer
appears in both the tty child frame as well as the main tty frame. Steps to
reproduce (again, using my test init.el from OP):
emacs -nw --init-directory=~/emacs-test
M-x emacs-version RET
(Note that when typing emacs-version, there are two visible minibuffers).
Secondly, the two tty behaviour seems screwy, in that the first time a
child frame is invoked on the second client, it doesn't get
populated/drawn. Steps:
emacs -nw --init-directory=~/emacs-test
Switch to another terminal, side by side so you can see and switch between
both easily
emacsclient -nw
M-x emacs-version RET
(runs fine, other than the two-minibuffer issue mentioned above)
Switch focus back to the first terminal
M-x emacs-version
(note the child frame appears with just the outside border drawn, as shown
below)
[image: image.png]
Third, in a continuation of the two tty scenario, keyboard input (e.g.
moving point) in one client instead takes effect in the other client! Steps:
emacs -nw --init-directory=~/emacs-test
Switch to another terminal, side by side so you can see and switch between
both easily
emacsclient -nw
M-x emacs-version RET
(runs fine, other than the two-minibuffer issue mentioned above)
Switch focus back to the first terminal
M-x emacs-version RET
(as above, the child frame isn't drawn, but the command itself runs)
Switch focus back to the second client
C-n C-f C-f (etc)
Note that the cursor is moving within the first client. Similarly, M-x
opens a tty child frame in the first client even though keyboard input is
coming from the second client.
On Sun, 16 Feb 2025 at 18:26, Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:
>
> On 15. Feb 2025, at 19:20, martin rudalics <rudalics <at> gmx.at> wrote:
>
> > Works perfectly, thanks!
>
> There's a problem with moving nested child frames out of their child
> parents. Load the attached tty-child-frames.el do first M-l and then
> C-M-l. You should see a grey child frame embedded in an orange child
> frame. Now do
>
> (set-frame-parameter tty-3 'left (- 30))
>
>
> Yep, I can reproduce it.
>
> Could be a problem with copying glyphs from the child to the root's
> desired matrix because the crash is from invalid glyph contents. When I
> reproduced it, the glyph in question was completely zeroed, for example.
>
> I've made bug#76321 for this. Can take me a bit to fix, I'm afraid.
>
[Message part 2 (text/html, inline)]
[image.png (image/png, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Wed, 26 Feb 2025 03:50:02 GMT)
Full text and
rfc822 format available.
Message #428 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Len Trigg <lenbok <at> gmail.com> writes:
> I thought I would check in and see if there was any changed behaviour
> with respect to this bug, and things seem to be worse if anything.
Which commit id is that?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Wed, 26 Feb 2025 04:12:02 GMT)
Full text and
rfc822 format available.
Message #431 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I'm currently on e60103f1309.
On Wed, 26 Feb 2025 at 16:49, Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:
> Len Trigg <lenbok <at> gmail.com> writes:
>
> > I thought I would check in and see if there was any changed behaviour
> > with respect to this bug, and things seem to be worse if anything.
>
> Which commit id is that?
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Wed, 26 Feb 2025 08:47:01 GMT)
Full text and
rfc822 format available.
Message #434 received at 75056 <at> debbugs.gnu.org (full text, mbox):
> First up, even just with a single tty emacs (i.e. no emacsclient), the
> minibuffer behaviour has changed, so that now it seems the minibuffer
> appears in both the tty child frame as well as the main tty frame. Steps to
> reproduce (again, using my test init.el from OP):
A child frame is supposed to show a minibuffer unless it is created with
(minibuffer . nil) or some value specifying a minibuffer on some other
frame. How precisely is your child frame created?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Wed, 26 Feb 2025 19:30:02 GMT)
Full text and
rfc822 format available.
Message #437 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, 26 Feb 2025 at 21:45, martin rudalics <rudalics <at> gmx.at> wrote:
> A child frame is supposed to show a minibuffer unless it is created with
> (minibuffer . nil) or some value specifying a minibuffer on some other
> frame. How precisely is your child frame created?
>
Sorry, my terminology may not be correct, I meant there are two "input
areas" at once (probably only the second one at the bottom of the frame is
an actual minibuffer?), see picture below:
[image: image.png]
The two input areas is not what we get when the same is invoked in GUI
rather than TTY (and not what the TTY behaviour used to be):
[image: image.png]
(In terms of how it's actually created, I guess that's in one of vertico /
posframe / vertico-posframe).
Cheers,
Len.
[Message part 2 (text/html, inline)]
[image.png (image/png, inline)]
[image.png (image/png, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Wed, 26 Feb 2025 19:42:02 GMT)
Full text and
rfc822 format available.
Message #440 received at 75056 <at> debbugs.gnu.org (full text, mbox):
Len Trigg <lenbok <at> gmail.com> writes:
> On Wed, 26 Feb 2025 at 21:45, martin rudalics <rudalics <at> gmx.at> wrote:
>
> A child frame is supposed to show a minibuffer unless it is created with
> (minibuffer . nil) or some value specifying a minibuffer on some other
> frame. How precisely is your child frame created?
>
> Sorry, my terminology may not be correct, I meant there are two "input
> areas" at once (probably only the second one at the bottom of the
> frame is an actual minibuffer?), see picture below:
>
> image.png
>
> The two input areas is not what we get when the same is invoked in GUI
> rather than TTY (and not what the TTY behaviour used to be):
Actually, you get the same thing with a GUI, but you don't notice. Feng
Shu, the author, can explain that better than me, but it goes something
like this:
The Posframe displays the minibuffer, but it doesn't have a minibuffer.
The actual minibuffer is still in the original frame, but it appears as
if it were not there because the mini-window's vscroll is set to
disguise that fact.
The trick doesn't work on ttys simply because I didn't implement vscroll
for ttys in Emacs 21.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#75056; Package
emacs.
(Wed, 26 Feb 2025 20:27:02 GMT)
Full text and
rfc822 format available.
Message #443 received at 75056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, 27 Feb 2025 at 08:41, Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:
> The Posframe displays the minibuffer, but it doesn't have a minibuffer.
> The actual minibuffer is still in the original frame, but it appears as
> if it were not there because the mini-window's vscroll is set to
> disguise that fact.
>
> The trick doesn't work on ttys simply because I didn't implement vscroll
> for ttys in Emacs 21.
>
Ahh apologies, so that first issue is a case of me misremembering what the
previous tty behaviour was like, and it's really the multiple clients cases
that are problematic (although in a different way to when this bug was
first opened).
Cheers,
Len.
[Message part 2 (text/html, inline)]
This bug report was last modified 110 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.