emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Minor fix for life.el.


From: David Kastrup
Subject: Re: Minor fix for life.el.
Date: Wed, 06 Sep 2006 20:34:02 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

address@hidden (Michaël Cadilhac) writes:

> David Kastrup <address@hidden> writes:
>
>> address@hidden (Michaël Cadilhac) writes:
>>
>>> I usually use M-x life with zero as numerical prefix (it's lot of fun).
>>> M-0 M-x life RET
>>>
>>> There's a little bug: when I hit a key, life goes into an infinite
>>> loop (not MY life) and I have to C-g to stop this.
>>>
>>> The following patch fixes this bug (sit-for is still called because he
>>> causes redisplay).
>>>
>>> Index: lisp/play/life.el
>>> ===================================================================
>>> RCS file: /sources/emacs/emacs/lisp/play/life.el,v
>>> retrieving revision 1.25
>>> diff -c -r1.25 life.el
>>> *** lisp/play/life.el       5 Feb 2006 14:10:44 -0000       1.25
>>> --- lisp/play/life.el       6 Sep 2006 16:58:35 -0000
>>> ***************
>>> *** 269,275 ****
>>>     (recenter 0)
>>>   
>>>     ;; Redisplay; if the user has hit a key, exit the loop.
>>> !   (or (eq t (sit-for sleeptime))
>>>         (throw 'life-exit nil)))
>>>   
>>>   (defun life-extinct-quit ()
>>> --- 269,276 ----
>>>     (recenter 0)
>>>   
>>>     ;; Redisplay; if the user has hit a key, exit the loop.
>>> !   (or (and (sit-for sleeptime) (< 0 sleeptime))
>>> !       (not (input-pending-p))
>>
>> That looks like the wrong fix.
>
> Damn!
>
>> How about
>>
>>       (or (eq t (sit-for (max sleeptime 0)))
>
> I don't think the (eq t)  is needed.

Right.

> However, the problem is not fixed by this as sit-for returns
> immediately `t' if its argument is zero (AFAICT).

Testing turns out that you are right.  I am surprised.  Further
testing showed that
(sit-for 1e-6)
returns t even if a key is pressed, while
(sit-for 1e-3)
returns nil when a key is pressed.

I think this behavior is not consistent enough to be fun.

> That's why I thought the check for input should be done by hand.

Probably the option least likely to require any changes even if
sit-for is about to change.

Kim, any idea whether this sit-for return value is turning out the way
you intended it?  At least the documentation says "t if waited for
whole time" and this does not imply that the keyboard needs to be
checked at all if the time has expired before it would have been worth
checking the keyboard.  But since pending keyboard is supposed to
inhibit redisplay for (sit-for 0), we can't avoid checking it anyway,
right?

And supposedly the return value of t from sit-for should at least
imply that a redisplay has occured and completed.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

[Prev in Thread] Current Thread [Next in Thread]