GNU bug report logs - #15045
Point jumps inappropriately around time of Semantic lexing

Previous Next

Full log

View this message in rfc822 format

From: Barry OReilly <gundaetiapo <at> gmail.com>
To: David Engster <deng <at> randomsample.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 15045 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>, "Eric M. Ludlam" <eric <at> siege-engine.com>
Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing
Date: Thu, 8 Aug 2013 16:03:30 -0400

>> Undesired scrolling is a downstream symptom. Upstream from it is
>> point visibly moving around inappropriately.

> I think you are wrong. Emacs moves point in its Lisp code all over
> the place, and that never causes any unwarranted scrolling, nor
> should it ever display point in anything but the final position --
> unless the Lisp code itself forces redisplay.

My use of the adverb "visibly" was meant to indicate redisplay of
point at other positions. Sorry to have confused you.

>   timer-event-handler([t 20995 27860 0 60 display-time-event-handler nil nil 0])
>   accept-process-output()
>   semantic-c-lexer(2886 7946 nil nil)

and

>   timer-event-handler([t 20995 36800 0 60 display-time-event-handler nil nil 0])
>   input-pending-p()
>   semantic-c-lexer(2939 7944 nil nil)

This is indeed a key finding.

If arbitrary timers can execute during the lexer's call to
accept-process-output or input-pending-p, then doesn't that mean
jit-lock-deferred-fontify can run too? If removing timers' sit-for
calls is the solution, then what's to become of
jit-lock-deferred-fontify's call to sit-for? Doesn't deferred jit
locking necessarily have to call redisplay?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.