bug-gnu-emacs
[Top][All Lists]
Advanced

[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.





reply via email to

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