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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: gundaetiapo <at> gmail.com, 15045 <at> debbugs.gnu.org, deng <at> randomsample.de, eric <at> siege-engine.com
Subject: bug#15045: Point jumps inappropriately around time of Semantic lexing
Date: Fri, 09 Aug 2013 17:16:39 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: deng <at> randomsample.de,  gundaetiapo <at> gmail.com,  15045 <at> debbugs.gnu.org,  eric <at> siege-engine.com
> Date: Fri, 09 Aug 2013 10:03:05 -0400
> 
> >> >> Right, that would do it.
> >> >> What happens if you remove the calls to sit-for from time.el?
> >> > You cannot ensure redisplay without that.
> >> I don't know what scenario you have in mind.
> > Any one.  Emacs enters redisplay for any number of reasons, but you
> > can never be sure it will do so at any specific point unless you force
> > redisplay at that point.  As you well know, in general, while Lisp
> > code runs, Emacs does not redisplay.
> 
> Of course, but that's true in general.  What makes it more true in
> display-time-event-handler?

Why should we care?  Good engineering does not build things on what
"currently happens to work", because that will eventually break,
given enough development.

> Remember that display-time-update (called just before the sit-for)
> ends with a call to force-mode-line-update.

Whose effect no one really understands.

> In practice, is there any important scenario where
> display-time-event-handler's sit-for is useful?

I never analyzed this to tell.

And anyway, display-time is just one case of a timer that needs to
force redisplay.

Previous Next

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