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

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

[Drew Adams]

(Not with emacs -Q, but with my setup.)
 
Dunno whether this helps, but I noticed this message in *Messages*,
apparently from mode-line display.  Why is such a message written to
*Messages* just because (seemingly) a user hits C-g during redisplay?

Is there an option that controls whether to print such messages?
 
QuitError during redisplay: (eval (\` ((-3 (\, (propertize "%p" (quote
local-map) mode-line-column-line-number-mode-map (quote mouse-face)
(quote mode-line-highlight) (quote help-echo) "Buffer position, mouse-1:
Line/col menu"))) (size-indication-mode (8 (\, (propertize (if (and
transient-mark-mode mark-active) (apply (function format) (mapcar
(function eval) modelinepos-style)) " of %I") (quote face) (and
transient-mark-mode mark-active (quote modelinepos-region)) (quote
local-map) mode-line-column-line-number-mode-map (quote mouse-face)
(quote mode-line-highlight) (quote help-echo) "Buffer position, mouse-1:
Line/col menu")))) (line-number-mode ((column-number-mode (10 (\,
(propertize " (%l,%c)" (quote face) (and (> (current-column)
modelinepos-column-limit) (quote modelinepos-column-warning)) (quote
local-map) mode-line-column-line-number-mode-map (quote mouse-face)
(quote mode-line-highlight) (quote help-echo) "Line and column, mouse-1:
Line/col menu"))) (6 (\, (propertize " L%l" (quote local-map)
mode-line-column-line-number-mode-map (quote mouse-face) (quote
mode-line-highlight) (quote help-echo) "Line number, mouse-1: Line/col
menu"))))) ((column-number-mode (5 (\, (propertize " C%c" (quote face)
(and (> (current-column) modelinepos-column-limit) (quote
modelinepos-column-warning)) (quote local-map)
mode-line-column-line-number-mode-map (quote mouse-face) (quote
mode-line-highlight) (quote help-echo) "Column number, mouse-1: Line/col
menu"))))))))) signaled (quit)
 
In GNU Emacs 24.2.50.1 (i386-mingw-nt5.1.2600)
 of 2012-10-15 on DANI-PC
Bzr revision: 110553 monnier@iro.umontreal.ca-20121015164957-6zms5w2js1xkldtg
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -I../../libs/libxpm-3.5.8/include -I../../libs/libxpm-3.5.8/src
 -I../../libs/libpng-1.4.10 -I../../libs/zlib-1.2.6
 -I../../libs/giflib-4.1.4-1/include -I../../libs/jpeg-6b-4/include
 -I../../libs/tiff-3.8.2-1/include
 -I../../libs/libxml2-2.7.8-w32-bin/include/libxml2
 -I../../libs/gnutls-3.0.16/include
 -I../../libs/libiconv-1.14-2-mingw32-dev/include'
 

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 22 Oct 2012 09:00:03 -0700
> 
> (Not with emacs -Q, but with my setup.)
>  
> Dunno whether this helps, but I noticed this message in *Messages*,
> apparently from mode-line display.

Can you try guessing which part of the expression could have barfed?

> Why is such a message written to
> *Messages* just because (seemingly) a user hits C-g during redisplay?

When some Lisp expression eval'ed by the display engine signals an
error, that error is caught and the message is written to *Messages*.
That's because redisplay cannot possibly let the message appear in the
echo area, as this will cause another redisplay, which will again
signal an error, and so on, ad nauseam.

So the problem here is that an error was signaled during evaluation of
a Lisp expression.  Are you sure that the cause was C-g?  The fact
that you see "Quit" does not yet prove it was a C-g that caused that.

> Is there an option that controls whether to print such messages?

Print where?

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

[Drew Adams]

> Can you try guessing which part of the expression could have barfed?

No.  This is the expression that was passed to `eval', and it is eval'd all of
the time during redisplay, with no problem:

`((-3 ,(propertize
        "%p" 'local-map mode-line-column-line-number-mode-map
        'mouse-face 'mode-line-highlight
        'help-echo "Buffer position, mouse-1: Line/col menu"))
  (size-indication-mode
   (8 ,(propertize
        (if (and transient-mark-mode mark-active)
            (apply #'format (mapcar #'eval mode linepos-style))
          " of %I") 'face (and transient-mark-mode mark-active
          'modelinepos-region)
        'local-map mode-line-column-line-number-mode-map
        'mouse-face 'mode-line-highlight
        'help-echo "Buffer position, mouse-1: Line/col menu")))
  (line-number-mode
   ((column-number-mode
     (10 ,(propertize
           " (%l,%c)"
           'face (and (> (current-column)
                         modelinepos-column-limit)
                      modelinepos-column-warning)
           'local-map mode-line-column-line-number-mode-map
           'mouse-face 'mode-line-highlight
           'help-echo "Line and column, mouse-1: Line/col menu"))
     (6 ,(propertize
          " L%l" 'local-map mode-line-column-line-number-mode-map
          'mouse-face 'mode-line-highlight
          'help-echo "Line number, mouse-1: Line/col menu"))))
   ((column-number-mode
     (5 ,(propertize
          " C%c" 'face (and (> (current-column)
                               modelinepos-column-limit)
                            'modelinepos-column-warning)
          'local-map mode-line-column-line-number-mode-map
          'mouse-face 'mode-line-highlight
          'help-echo "Column number, mouse-1: Line/col menu"))))))

Do you see anything problematic in that sexp?  I don't.

> > Why is such a message written to *Messages* just because (seemingly)
> > a user hits C-g during redisplay?
> 
> When some Lisp expression eval'ed by the display engine signals an
> error, that error is caught and the message is written to *Messages*.
> That's because redisplay cannot possibly let the message appear in the
> echo area, as this will cause another redisplay, which will again
> signal an error, and so on, ad nauseam.

That I understood.  I got the (mistaken?) impression that this message was
printed out because of a user quit during redisplay.

> So the problem here is that an error was signaled during evaluation of
> a Lisp expression.  Are you sure that the cause was C-g?  The fact
> that you see "Quit" does not yet prove it was a C-g that caused that.

No, I certainly am not sure of anything regarding this.  I do know that that
sexp is eval'd and the mode line updated accordingly zillions of times
throughout every one of my Emacs sessions, with no problem.  That, together with
the "signaled (quit)" led me to think that it was a C-g that caused the message
printing.

Are you sure that the cause was not C-g?  Why print "signaled (quit)" if there
was no quit signal?  Or is that supposed to mean (a) an error was signalled (not
a quit) and so (b) redisplay then quit?

> > Is there an option that controls whether to print such messages?
> 
> Print where?

To *Messages*.  But I guess there is not, since you say that this is the normal
handling of an eval error and did not come from C-g.  I understand that such a
message would be printed for a real (display) error.  What seemed odd was that
it would be done for C-g during redisplay.  That's what I thought was happening.

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

[Stefan Monnier]

> Are you sure that the cause was not C-g?

We have no idea.  Eli was just pointing out that a `quit' signal can
also be generated without the user hitting C-g, although it's admittedly
very unusual.  But while rendering the mode-line, inhibit-quit is
non-nil normally, so hitting C-g should presumably not signal `quit' in
your code.

> To *Messages*.  But I guess there is not, since you say that this is
> the normal handling of an eval error and did not come from C-g.
> I understand that such a message would be printed for a real (display)
> error.  What seemed odd was that it would be done for C-g during
> redisplay.  That's what I thought was happening.

The message should not be printed, because what happened is something
which shouldn't happen.  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'?


        Stefan

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <12704@debbugs.gnu.org>
> Date: Mon, 22 Oct 2012 10:56:59 -0700
> 
> > Can you try guessing which part of the expression could have barfed?
> 
> No.  This is the expression that was passed to `eval', and it is eval'd all of
> the time during redisplay, with no problem:
> 
> `((-3 ,(propertize
>         "%p" 'local-map mode-line-column-line-number-mode-map
>         'mouse-face 'mode-line-highlight
>         'help-echo "Buffer position, mouse-1: Line/col menu"))
>   (size-indication-mode
>    (8 ,(propertize
>         (if (and transient-mark-mode mark-active)
>             (apply #'format (mapcar #'eval mode linepos-style))
>           " of %I") 'face (and transient-mark-mode mark-active
>           'modelinepos-region)
>         'local-map mode-line-column-line-number-mode-map
>         'mouse-face 'mode-line-highlight
>         'help-echo "Buffer position, mouse-1: Line/col menu")))
>   (line-number-mode
>    ((column-number-mode
>      (10 ,(propertize
>            " (%l,%c)"
>            'face (and (> (current-column)
>                          modelinepos-column-limit)
>                       modelinepos-column-warning)
>            'local-map mode-line-column-line-number-mode-map
>            'mouse-face 'mode-line-highlight
>            'help-echo "Line and column, mouse-1: Line/col menu"))
>      (6 ,(propertize
>           " L%l" 'local-map mode-line-column-line-number-mode-map
>           'mouse-face 'mode-line-highlight
>           'help-echo "Line number, mouse-1: Line/col menu"))))
>    ((column-number-mode
>      (5 ,(propertize
>           " C%c" 'face (and (> (current-column)
>                                modelinepos-column-limit)
>                             'modelinepos-column-warning)
>           'local-map mode-line-column-line-number-mode-map
>           'mouse-face 'mode-line-highlight
>           'help-echo "Column number, mouse-1: Line/col menu"))))))
> 
> Do you see anything problematic in that sexp?  I don't.

If you have size-indication-mode turned on, I'd look at the mapcar
part, like Stefan suggests.

> I got the (mistaken?) impression that this message was printed out
> because of a user quit during redisplay.

It could be the case, but then it's a bug somewhere, as redisplay
generally disables quitting.

> Are you sure that the cause was not C-g?

No.

> Why print "signaled (quit)" if there was no quit signal?

Quit signal can be generated by something that is not C-g. It could
come from evaluating a menu item, for example, or from a canceled
menu.

> Or is that supposed to mean (a) an error was signalled (not a quit)
> and so (b) redisplay then quit?

No, it really means that some Lisp form signaled quit, or C-g was
pressed while a Lisp form was evaluated without inhibiting quitting.

> > > Is there an option that controls whether to print such messages?
> > 
> > Print where?
> 
> To *Messages*.

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

> I understand that such a message would be printed for a real
> (display) error.  What seemed odd was that it would be done for C-g
> during redisplay.  That's what I thought was happening.

It did.  When redisplay needs to eval some Lisp, it does so in a way
that catches any signals thrown by that Lisp.  When such a signal is
caught, the message you see is inserted into *Messages*.

The quit signal could come either from the eval'ed Lisp, or because
you typed C-g while inhibit-quit was not set, which will cause the
Lisp evaluation to be canceled by the quit signal.

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.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: "'Eli Zaretskii'" <eliz@gnu.org>, <12704@debbugs.gnu.org>
> Date: Mon, 22 Oct 2012 13:39:26 -0700
> 
> > 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.

There's no contradiction here.  Stefan says that the message is not
expected, i.e. it's an emergency.  I explained that _if_ these
messages are issued, they are put into *Messages*.

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

That's the plan, yes.  But bugs are so creative...

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

That's the suspicion, yes.

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

Yes, this should be taken care of.  I think.

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

[Drew Adams]

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

FYI, I think I found the culprit.  In my file icomplete+.el I redefine some
functions from icomplete.el.  I include macro `while-no-input' in the file so
that the file can be byte-compiled in Emacs versions prior to Emacs 23 and the
byte-compiled file used with Emacs 23.  I include macro `with-local-quit' too,
because it is used by `while-no-input'.  And macro `with-local-quit' binds
`inhibit-quit' to nil.

So most likely I hit C-g while the mode line was being redisplayed, which caused
the redisplay code to print that error msg to *Messages*.

It happened again today, when I was trying to use the debugger with icomplete
code.

Error during redisplay: (eval (mode-line-eol-desc)) signaled (quit)



[BTW, I also got this unrelated internal error when trying to test some related
code:
Error in post-command-hook ((lambda nil (let ((non-essential t)) (run-hooks
(quote icomplete-post-command-hook))))): (error "Internal error: *scratch*
doesn't match \\`mcs")]

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

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> It happened again today, when I was trying to use the debugger with icomplete
> code.
>
> Error during redisplay: (eval (mode-line-eol-desc)) signaled (quit)

Ok, then this doesn't seem to be a bug.  Closing.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/