Subject: Re: bug#30182: Update

From: martin rudalics <[email-masked]>
Date: Fri, 02 Feb 2018 09:28:18 +0100

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