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

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Cc: gundaetiapo@gmail.com,  monnier@iro.umontreal.ca,  15045@debbugs.gnu.org, 
>  eric@siege-engine.com
> Date: Fri, 09 Aug 2013 18:10:04 +0200
> 
> >> >> However, doing redisplay in timers is not nice.
> >> >
> >> > Why not?
> >> 
> >> Because doing redisplay is a user-visible side effect, and in general,
> >> timers shouldn't have those.
> >
> > How else can a timer such as that of display-time do its thing?  IOW,
> > when the purpose of a timer is to cause something to be displayed,
> > they have no alternative but to force redisplay.
> 
> As you know, Emacs does not have strict timers. If you say to Emacs: one
> minute from now, say 'foo', and Emacs happens to be busy one minute from
> now, nothing will happen until it waits again. So I wonder: with such a
> lenient definition of "timer", does the wait for the next redisplay
> really matter?

Emacs very seldom is busy for a long time, so in practice you will see
the 1-min timer do its thing pretty much on time.

> After which idle time does redisplay kick in anyway?

Redisplay doesn't count idle time to kick in, so there's no answer to
your question.  Redisplay is triggered by several reasons, one of them
being waiting for keyboard input, which you might call "being idle",
although that's not exactly accurate.

> As a sidenote: What "bunch of useful features" do you have in mind for
> non-idle timers that do redisplay? They shouldn't alter buffer content,
> so what can they do that would need immediate redisplay? Displaying some
> kind of progress/time indicator is pretty much the only thing I can come
> up with.

Any display-related feature, such as blinking something, displaying
something ion the mode line or header line, etc.  Altering a buffer
can be one of the effects, btw, e.g. in a feature that shows the list
of processes on a system and refreshes that list every second.

> > IOW, it's the caller of input-pending-p etc. that is the fault here,
> > not the timers that it inadvertently lets run.
> 
> Until yesterday, I was completely unaware that `accept-process-output'
> or `input-pending-p' could run timers that do redisplay, and I think I'm
> in good company. The doc-strings do not mention it, so there must be
> lots of third-party code which does not pay attention to this, so we
> should try that this bug triggers as little as possible.

I agree that the doc strings should make a prominent reference to this
issue.

> >> In fact, I just understood another bug in speck-mode (which is similar
> >> to flycheck). I sometimes had unwanted scrolls there, too, and I now saw
> >> that those also happen at every full minute while typing.
> >
> > Then there's the same bug there, that's all.
> 
> Yes. But it shows that this bug is easy to make, and it's hard to track
> down.

It is also very rare.