GNU bug report logs - #12326
24.2.50; js2-mode freezes on current trunk

Previous Next

Package: emacs;

Reported by: Dmitry Gutov <dgutov <at> yandex.ru>

Date: Sat, 1 Sep 2012 22:00:02 UTC

Severity: normal

Merged with 12447

Found in versions 24.1.50, 24.2.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 12326 <at> debbugs.gnu.org
Subject: Re: bug#12326: 24.2.50; js2-mode freezes on current trunk
Date: Sun, 02 Sep 2012 17:03:53 +0400
Hi Jan,

On 02.09.2012 12:35, Jan Djärv wrote:
> 1 sep 2012 kl. 23:57 skrev Dmitry Gutov <dgutov <at> yandex.ru>:
>
>> js2-mode freezes during editing in some buffers.
>>
>> This has been a long-standing complaint on Mac OS X port, but now it
>> affect Linux and Windows users too, see
>> https://github.com/mooz/js2-mode/issues/49
>>
>> Bisecting the Bazaar history (on a Windows machine) points to the
>> month-old commit no 109470, which adds one line in `timer_check_2'.
>>
>
> The reason for that line is to make timer_check return the time to the next timeout, not the time to some random timer.

How was it random? AFAICT, your line just breaks out of the "while" loop 
when a ripe timer is found, and so `timer_check_2' returns 0 time, and 
its caller (timer_check) calls it again.
And before that the while loop in `timer_check_2' just ran until it 
reached the end of timers lists, or found a non-ripe timer.

I think the main difference is, previously, `timer_check_2' was called 
only once, so `now' and `idleness_now' were calculated at that time, and 
all timers were checked for ripeness against those values.

Now `now' and `idleness_now' are recalculated after each time a ripe 
timer fires, which is arguably more correct (some time has passed, after 
all), but doesn't leave the room for the event loop to detect new 
keypresses and update `timer_idleness_start_time'.

> When a dialog i shown, the time to the next time is checked with timer_check and when that time is reached, the timer is run.  If timer_check returns an out of order time, timers are not run when they should be.

Didn't they they just run a little late, due to the time values, against 
which the difference was calculated, being slightly outdated?

> I'm surprised that js2 functions with undefined behaviour and not with defined behaviour.

Looks like the previous behavior was more conservative.

I think js2-mode is only unusual in that it may schedule a new timer 
from within a timer callback function.

--Dmitry




This bug report was last modified 12 years and 248 days ago.

Previous Next


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