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

[Stefan Monnier <monnier@iro.umontreal.ca>]

> FWIW, I'm against such changes.  You can never know how many places
> will be subtly broken by changes like that in such a popular
> interface.

Hmm... I kind of agree with both:
- this is a subtle change affecting behavior in a corner case and it's
  difficult to know which code might care about it.
- nothing in input-pending-p indicates this is some kind of
  blocking/waiting operation which might hence correspond to a "yield
  point".  On the contrary, the intuition behind input-pending-p would
  make you think that the whole point of it is to let you find out if
  there's input *without waiting*.

So I tend to agree with Barry that input-pending-p should not run
timers.  Not just based on his particular problem case, but on the basis
of what ideally input-pending-p should do.

Arguably it shouldn't process_special_events either, tho obviously,
removing this call would introduce a known breakage, so we should keep
this for now (until we have a better fix for it).
  
> The original problem is rare enough, and should IMO be fixed in the
> code where it happens.

It can be difficult to "fix" it there, because there's simply no other
operation that lets you detect if there's input in the queue without
running arbitrary code, so it can require non-trivial refactoring.

>> > What if input arrives because of a timer?
>> If this is an issue, I propose input-pending-p return t if a timer is
>> ready to run.
> Likewise: too serious change in behavior for too obscure a reason.

100% agreement.  `input-pending-p' is meant to detect *user input*, and
timers do not count as such (and input generated by timers doesn't
count as "user input" either).


        Stefan