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

Previous Next

Full log

Message #188 received at 15045 <at> debbugs.gnu.org (full text, mbox):

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

[Message part 1 (text/plain, inline)]

> The easiest solution is to add an optional argument `check-timers'
> to input-pending-p, so you can preserve the exact same behavior.

I assume you mean no-check-timers, nil being default.

> In the long run, we should try and clean up sit-for, but you may not
> have the courage to dig into this right now.

I'm arguing I don't need to dig into sit-for's complexity to maintain
its current behavior. If (sit-for 0 ...) calls something like
thread-yield which in turn calls timer_check, then all ways of calling
sit-for would have unchanged behavior.

Even so, because of other calls to input-pending-p not through
sit-for, there could conceivably be regressions in the latencies of
timers, due to background tasks not yielding when they used to. If we
discovered such cases, the solution is straight forward: replace
(input-pending-p) with (sit-for 0 t) in the offending background task.
But I understand the objection.

If the no-check-timers arg solution is what you want, I'll prepare a
patch to add it and have Semantic and NXML use it.

Also, what do you think are the merits of putting in the
specpdl-walking check discussed earlier, enabled with
--enable-checking? I can't see a legit case where check_timers is
called when point is on an excursion. Such code should not make any
assumptions about the other timers the user is running which might
call redisplay.

> The current state of the concurrency branch is not always
> representative of what it should ideally look like ;-) But even if
> timers are made to belong to a thread, thread-yield should probably
> check timers.

The timer behavior on the concurrency branch seems reasonable. Moving
them to their own threads might be complex, not least because of
concerns that the global lock will be yielded often enough to not
regress timer latencies.

[Message part 2 (text/html, inline)]

Previous Next

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