From: Eli Zaretskii <eliz@gnu.org>
To: Drew Adams <drew.adams@oracle.com>
Cc: 12515@debbugs.gnu.org
Subject: bug#12515: 24.2.50; Error during redisplay: (eval (mode-line-eol-desc)) signaled (quit)
Date: Tue, 25 Sep 2012 23:11:04 +0200 [thread overview]
Message-ID: <83obkthkpj.fsf@gnu.org> (raw)
In-Reply-To: <92DF3648D1164884A80C7CA71D1DBF1A@us.oracle.com>
> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <12515@debbugs.gnu.org>
> Date: Tue, 25 Sep 2012 13:51:38 -0700
>
> I guess part of what you are saying (implying) is that _quitting_ (C-g), because
> it involves signalling, also "normally re-enters redisplay (to display the" quit
> message).
Yes. But there are places in Emacs that signal 'quit' for other
reasons, AFAICS.
> Sounds like `mode-line-eol-desc' should disable quitting only if it is
> guaranteed to end quickly.
If it doesn't end quickly, redisplay will become sluggish, and people
will promptly complain that, say, C-f takes too long. In general,
anything that is called as part of redisplay must be quick, for that
very reason.
> When you say "disable quitting", do you mean that the user would need to hit
> `C-g' again, or only that the `C-g' would not be processed until after redisplay
> finishes (i.e., respects a previously set `quit-flag')?
The latter.
> BTW, I looked in `(elisp) Quitting' for some explanation of this, but it does
> not seem to mention "display" or "redisplay" at all. (It does mention C code,
> however.)
It's not quitting that re-enters redisplay, it's the 'quit' signal
that is caused by it, when it is caused by it.
But yes, documentation of the Emacs display engine leaves a lot to be
desired. Luckily, Lisp programmers don't normally need to know too
much about that, and the simple "natural" mental model will usually
do.
prev parent reply other threads:[~2012-09-25 21:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-25 18:33 bug#12515: 24.2.50; Error during redisplay: (eval (mode-line-eol-desc)) signaled (quit) Drew Adams
2012-09-25 20:18 ` Eli Zaretskii
2012-09-25 20:22 ` Drew Adams
2012-09-25 20:37 ` Eli Zaretskii
2012-09-25 20:51 ` Drew Adams
2012-09-25 21:11 ` Eli Zaretskii [this message]
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=83obkthkpj.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=12515@debbugs.gnu.org \
--cc=drew.adams@oracle.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.