bug#30182: Update

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 01 Feb 2018 10:26:28 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org>, 30182@debbugs.gnu.org
> 
>  > With the patch applied on top of master, this message is printed in
>  > *Messages* when the mouse cursor is moved over the modeline. It happens
>  > only once.
> 
> Thank you very much.
> 
>  > Error during redisplay: (eval (w3m-modeline-title)) signaled (error "Attempt to add [t 23154 31461 636625 nil #[(buffer) \\302\b!\\205\0r\bq\\210\\303\\211)\\207 [buffer w3m-modeline-title-timer buffer-live-p nil] 2] (*w3m*) nil 113000] to ([nil 23154 31461 622052 0.5 blink-cursor-timer-function nil nil 870000] [nil 23154 31476 0 60 display-time-event-handler nil nil 0] [nil 23154 31747 353232 300 savehist-autosave nil nil 708000]) while checking timers")
> 
> The behavior differs slightly from those seen earlier because the
> timer list contains only three timers when it tries to add another
> one.  Still the conjecture that we try to add a timer while checking
> timers has been proven.

I'd love to see a C-level backtrace from that situation, because I'm
not really sure what exactly happens and how.

> So it seems that we do something we are supposed to avoid - call Lisp
> from asynchronous redisplay as a consequence of some mouse movement
> (presumably).

"Asynchronous redisplay" could only mean the call to expose_frame, is
that right?  I'm not aware of any other asynchronous entry to
redisplay.  We could call expose_frame asynchronously if a mouse
movement caused the SIGIO signal be delivered to Emacs while
copy-sequence did its job.  The SIGIO handler then could call
gobble_input, which would read the X events from the socket, see the
Expose event and call expose_frame, or see the MotionNotify event and
call note_mouse_highlight.  However, neither of these is supposed to
call Lisp, or evaluate the mode-line format (which would call Lisp via
:eval), or at least I couldn't see any such call.  Both expose_frame
and note_mouse_highlight just redraw the glyphs that are already
computed by the previous redisplay cycle.

So I'm still unsure what is going on here.  But if indeed the above
scenario somehow ends up calling Lisp from the async redisplay,
wrapping the call to Fcopy_sequence in timer_check with block_input
and unblock_input should solve the problem, right?

Thanks.