bug#15045: Point jumps inappropriately around time of Semantic lexing

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  David Engster <deng@randomsample.de>,  gundaetiapo@gmail.com,  15045@debbugs.gnu.org
> Date: Fri, 09 Aug 2013 10:04:41 -0400
> 
> > In my mind, to anyone using input-pending-p to deal with responsiveness in
> 
> Actually, now that I think about it.  Why would input-pending-p
> run timers?

The code is very explicit:

  DEFUN ("input-pending-p", Finput_pending_p, Sinput_pending_p, 0, 0, 0,
	 doc: /* Return t if command input is currently available with no wait.
  Actually, the value is nil only if we can be sure that no input is available;
  if there is a doubt, the value is t.  */)
    (void)
  {
    if (!NILP (Vunread_command_events)
	|| !NILP (Vunread_post_input_method_events)
	|| !NILP (Vunread_input_method_events))
      return (Qt);

    /* Process non-user-visible events (Bug#10195).  */
    process_special_events ();

    return (get_input_pending (READABLE_EVENTS_DO_TIMERS_NOW
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
			       | READABLE_EVENTS_FILTER_EVENTS)
	    ? Qt : Qnil);


> That sounds wrong.

Are you saying that using the READABLE_EVENTS_FILTER_EVENTS flag above
is wrong?

> Of course, fixing it won't change anything to the OP's problem since he
> also has backtraces where the problem is triggered via
> accept-process-output.

Right.  Emacs generally always runs timers when it waits.