Re: Weird behavior and crash with X and TTY frame

[Eli Zaretskii]

> From: Jan Djärv <address@hidden>
> Date: Sun, 7 Apr 2013 14:06:46 +0200
> Cc: Emacs development discussions <address@hidden>
> 
> This is something Emacs can't handle.  It is because how the lisp and event 
> loop interracts.
> 
> When you do (x-popup-dialog t '("Test" ("yes" . 1))), a Lisp return value is 
> expected back to the Lisp code.  So Emacs does not execute any more Lisp, 
> until the dialog is popped down.
> The popup is shown by a loop that just processes X events 
> (x_menu_wait_for_event).
> When you switch frame and do C-g C-g, the "normal" stuff does not happen, 
> because Lisp is not executed.
> 
> This would be solvable if we had an independent Lisp loop per terminal, but 
> it is not so.
> There is only one Lisp loop, shared by all frames/terminals, and if one 
> frame/terminal suspends the loop, it is suspended for all frames/terminals.

Actually, this isn't a problem at all.  It's a (very old) feature,
called "emergency escape": when Emacs is stuck in some prolonged
computation or loop, typing C-g twice on a TTY invokes this behavior,
whereby the TTY is first suspended, to get the user a chance to
investigate what's wrong (in case there are no other windows to do
that, but just a single console), and then, after Emacs is resumed, it
offers to dump core, so that the problem could be looked into with a
debugger.  See the node "Emergency Escape" in the user manual.

The only misfeature in this scenario is that the "loop" in this case
is processing X events for a dialog we popped up ourselves.

FWIW, I don't see any particular problem here.  To make things more
explicit, perhaps x-popup-dialog should set some variable that
handle_interrupt could test and display some descriptive message in
the echo area, so the user would know that the X frame is in a modal
state.