bug#30182: Update

[martin rudalics]

> "Asynchronous redisplay" could only mean the call to expose_frame, is
> that right?

That's what I meant, yes.

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

note_mouse_highlight calls note_mode_line_or_margin_highlight which
does

                  help_echo_string = (FUNCTIONP (default_help)
                                      ? safe_call1 (default_help, window)
                                      : default_help);

We could instrument the code around this to do something special when
Vtimer_check_in_progress is non-nil.

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

But we can't do that, right?  Users should be able to cancel it.

martin