[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#16479: 24.3.50; daemon freeze with tty menus

From: Stefan Monnier
Subject: bug#16479: 24.3.50; daemon freeze with tty menus
Date: Fri, 17 Jan 2014 11:16:26 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

> Why does the connection attempt from the second client accepted when
> we switch to a single keyboard?  I expected it to be rejected.

I don't think we have a mechanism to reject it (and usually it wouldn't
be the right thing to do either, because in most cases there's only
a single physical user behind the two connections, so the most recent
one is the one she cares about right now).

Instead, emacsclient does:

  (when (> (recursion-depth) 0)
    ;; We're inside a minibuffer already, so if the emacs-client is trying
    ;; to open a frame on a new display, we might end up with an unusable
    ;; frame because input from that display will be blocked (until exiting
    ;; the minibuffer).  Better exit this minibuffer right away.
    ;; Similarly with recursive-edits such as the splash screen.
    (run-with-timer 0 nil (lambda () (server-execute-continuation proc)))

So, ideally (recursion-depth) should be >0 when inside the tty menus,
and calling (top-level) should get us out of that tty menu.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]