bug#12704: 24.2.50; QuitError during redisplay: (eval (\` ((-3 (\, (propertize "%p" ...

[Drew Adams]

> The message should not be printed, because what happened is something
> which shouldn't happen.

Hm.  FWIW, Eli's msg seems to contradict that:

  "They are always printed to *Messages*, as redisplay has no
   other ways of recording these errors that don't re-enter redisplay.

Which makes sense.

>From what I gather from your reply and his, a quit signal from C-g (but not 
>from
code?) during mode-line redisplay normally does not result in such a message in
*Messages*, because the redisplay code binds `inhibit-quit' to non-nil while it
does its thing.

So if the msg resulted from my hitting C-g then the fact that the message is
present indicates that something must have changed `inhibit-quit' to nil.

FWIW, this is the only time I've seen such a msg.

> I'm not sure how best to try and 
> track down the source of this `quit' signal, OTOH.
> 
> The only non-negligible computation in your expression seems 
> to be a few calls to `current-column'
> Oh, wait, there's also the "mapcar #'eval" which could potentially do
> something non-trivial, so you might want to look in there, see if some
> of the code run from there might let-bind inhibit-quit back 
> to nil or if it might signal `quit'?

This is the list that `eval' is mapped over:

 (" %d ch, %d l"
  (abs (- (mark t) (point)))
  (count-lines (mark t) (point)))

(`format' is then applied to that result.)

I don't see anywhere that `inhibit-quit' could be bound to nil in that code.
But I didn't recursively check the def of each function that is called by
`count-lines'.

I imagine that it could be bound to nil more generally, in some operation during
which the mode line happened to get updated by display.  But that is presumably
already taken care of - I imagine that the binding to non-nil happens when
mode-line updating begins.