From: "Gerd Möllmann" <gerd.moellmann@gmail.com>
To: Len Trigg <lenbok@gmail.com>
Cc: 75056@debbugs.gnu.org
Subject: bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs
Date: Fri, 27 Dec 2024 07:04:54 +0100 [thread overview]
Message-ID: <m28qs1hda1.fsf@gmail.com> (raw)
In-Reply-To: <CAOGVwemgaN4WN_GpNNfkm0fPbj3g-2=DNy-K0N6LxEH+KYRN1Q@mail.gmail.com> (Len Trigg's message of "Tue, 24 Dec 2024 18:43:29 +1300")
Len Trigg <lenbok@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.
next prev parent reply other threads:[~2024-12-27 6:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-24 5:43 bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs Len Trigg
2024-12-25 11:54 ` Eli Zaretskii
2024-12-25 11:59 ` Gerd Möllmann
2024-12-27 6:04 ` Gerd Möllmann [this message]
2024-12-27 8:18 ` Eli Zaretskii
2024-12-27 8:46 ` Gerd Möllmann
2024-12-27 8:54 ` Eli Zaretskii
2024-12-27 9:04 ` Gerd Möllmann
2024-12-27 12:28 ` Eli Zaretskii
2024-12-27 12:47 ` Gerd Möllmann
2024-12-27 13:02 ` Eli Zaretskii
2024-12-27 13:17 ` Gerd Möllmann
2024-12-27 14:53 ` Eli Zaretskii
2024-12-27 15:56 ` Gerd Möllmann
2024-12-27 18:13 ` Len Trigg
2024-12-27 18:23 ` Len Trigg
2024-12-28 7:52 ` Eli Zaretskii
[not found] ` <CAOGVwenNt8a0HmSXTnqu5_FKkxEVMDw0hmak-MLk7Sn6up_wtg@mail.gmail.com>
2024-12-28 7:44 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m28qs1hda1.fsf@gmail.com \
--to=gerd.moellmann@gmail.com \
--cc=75056@debbugs.gnu.org \
--cc=lenbok@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.