[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: Mark Oteiza
Subject: bug#16479: 24.3.50; daemon freeze with tty menus
Date: Fri, 17 Jan 2014 05:21:51 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: Mark Oteiza <address@hidden>
>> Date: Fri, 17 Jan 2014 04:39:55 -0500
>> >From emacs --daemon -Q:
>> $ emacsclient -t
>> M-x menu-bar-mode RET <F10>
>> At this point, the daemon is started, and a client is open with a tty
>> menu selected.  Leaving the first client alone, open a new one
>> $ emacsclient -t
>> Now emacs is frozen.
> It's not frozen, it waits for you to finish the menu input.  The same
> happens if you type, e.g., "C-x" in one client and then switch to the
> other: it will be unresponsive until you finish typing the command in
> the first one.
> Emacs reads only from one keyboard at a time.
> This is not a bug, but a well-known limitation of multi-tty input in
> Emacs.

Ok.  I understand that emacs has to wait for input.  With menu-bar-mode
disabled, I can open a menu in client A with F10, open another client B
somewhere else, return to client A and do whatever with the menu.

With menu-bar-mode (and thus the new tty menus) enabled, if I do the
steps I outlined above, I expect to be able to return to the previous
client and finish input.  This is not the case: if I go back to the
first client with the menu, and try an arrow key or C-{npbf}, emacs
crashes.  I think this is a bug.

I realize I failed to communicate the problem in my first email.

reply via email to

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