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

[Eli Zaretskii <eliz@gnu.org>]

> 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 07:36:07 +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.

> AFAICS, any function that calls things like
> `accept-process-output', `input-pending-p' or `sit-for' inside a
> `save-excursion' might get an unwanted scrolling effect if point is
> temporarily moved to some invisible location.

You mean, because of timers that might get run and cause redisplay?
Yes, that's possible.  But the way to avoid this is to never call
these when point is in a place the user won't expect.  Forcing the
Emacs community not to trigger redisplay inside timers is IMO _not_
the right way, because this is unnecessarily restrictive, and would
disallow a whole bunch of useful features for no good reason.

IOW, it's the caller of input-pending-p etc. that is the fault here,
not the timers that it inadvertently lets run.

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

Doing things in the background is hard in Emacs, so it's a small
wonder some modes get it wrong.

> >> > Doesn't deferred jit locking necessarily have to call redisplay?
> >> 
> >> I would think so, too.
> >
> > But since jit-lock-deferred-fontify only happens when Emacs is idle,
> > there's no problem with that, since Emacs enters redisplay also when
> > it is idle.
> 
> I thought that the jit-lock timer is a non-idle timer, but you are
> right.

There's no jit-lock timer.  There are timers for jit-lock-stealth and
for jit-lock-deferred-fontify (both optional features), and they are
all idle timers.  JIT Lock itself is not triggered by any timer, it is
invoked by redisplay when a portion of text that is not fontified yet
comes into view.