From: Eli Zaretskii <eliz@gnu.org>
To: "Jan Djärv" <jan.h.d@swipnet.se>
Cc: dmantipov@yandex.ru, emacs-devel@gnu.org
Subject: Re: Weird behavior and crash with X and TTY frame
Date: Sun, 07 Apr 2013 18:36:10 +0300 [thread overview]
Message-ID: <83li8ucpzp.fsf@gnu.org> (raw)
In-Reply-To: <A0C28228-46D0-431B-A84F-77709146BB7E@swipnet.se>
> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Sun, 7 Apr 2013 14:06:46 +0200
> Cc: Emacs development discussions <emacs-devel@gnu.org>
>
> 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.
next prev parent reply other threads:[~2013-04-07 15:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-06 13:03 Weird behavior and crash with X and TTY frame Dmitry Antipov
2013-04-07 12:06 ` Jan Djärv
2013-04-07 15:18 ` Dmitry Antipov
2013-04-07 15:40 ` Eli Zaretskii
2013-04-07 15:36 ` Eli Zaretskii [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-04-07 15:02 grischka
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=83li8ucpzp.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=dmantipov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=jan.h.d@swipnet.se \
/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.