[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12515: 24.2.50; Error during redisplay: (eval (mode-line-eol-desc))
From: |
Eli Zaretskii |
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 |
> 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.