bug#30182: Update

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 02 Feb 2018 09:28:18 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: m.sujith@gmail.com, 30182@debbugs.gnu.org
> 
>  > "Asynchronous redisplay" could only mean the call to expose_frame, is
>  > that right?
> 
> That's what I meant, yes.

Actually, mouse movement could also cause that, via the MotionNotify
event that calls note_mouse_highlight.  Right?

> 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);

Does this mean we can now actually call Lisp asynchronously upon every
mouse movement?  That's a definite no-no.

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

We could bind inhibit-eval-during-redisplay to a non-nil value.
However, that will disable your function, and defeat the whole purpose
of making mode-line-default-help-echo a function.

But I think the problem introduced by this recent change, which allows
Lisp to be called asynchronously, is a much more serious problem than
just timer_check.  We _cannot_ call Lisp asynchronously in any safe
way.  I'm afraid we will have to roll back the change which allowed
mode-line-default-help-echo to be a function.  Can you find an
alternative way of achieving the same effect, that doesn't call Lisp
from note_mode_line_or_margin_highlight?

I think we should introduce some protection against making such
implementation mistakes in the future.  Like some flag that we set
when redisplay is entered asynchronously, and that is checked in
safe__call, where we'd signal an error (or maybe even abort, under
"--enable-checking") if the flag is set.  This should allow us to find
such problems much faster.  WDYT?