all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.








  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.