[Top][All Lists]

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

Re: idledo.el v. 0.3

From: D . Goel
Subject: Re: idledo.el v. 0.3
Date: 24 Oct 2002 10:25:39 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

address@hidden (Kim F. Storm) writes:

> > IMHO, This one is the only "important" case that does not get covered.
> > Though it may seldom be needed in practice, it would seem awkward to
> > leave this out.  
> I honestly fail to see how that is of any practical use.  

I agree about the not-of-much-practical use thingy.. I was more
concerned about "doing the right thing" --- all other "missing"
functionalitites can easily be implemented the user herself by
tweaking their function (and hence of no more concern to me) .  The
above was the only remaining case which i didn't see a way that user
could implement --- i thought that if, for some weird impractical
reason, they want to implement such a timer, they would have to go
back to using either the sit-for (as in timerfunctions.el) or
pre-command-hook (as in blink-cursor-mode), both of which seem kludgy
and "wrong". 

> But it could be handled by overloading the REPEAT argument so that
> if it is a negative number, it means repeat every -REPEAT seconds
> after first being idle, but don't repeat on next emacs idle.

I like this one too! :)

> Yes, that's always a possibility ...  actually, it would seem to be
> useful to also have a "no longer idle" handler for an idle-timer which


> I suppose your primary interest is to be able to know whether a given
> idle-timer is activated for the first time after emacs becoming idle
> , or whether it is a repeated activation in the same idle period;


> for that purpose, the first element of the timer vector could
> provide the necessary information (as it would be t on first
> invocation).

If this is so, then I am indeed satisfied.  :) ...

BTW, I think there's not documentation for what exactly the idle-timer
vector stores [other than one layout-line], anywhere.  Neither in the
elisp manual, nor in timer.el .  Moreover, it seemed that was not easy
to figure that stuff out from even studying the lisp code of timer.el,
it seems the only way would be to try to study the C code :(

(In particular, it is not clear to me why the triggerred-p (the first
element of the timer-vector) would not be t on subsequent invocations
within a given idle-period, as you mention above.)

So, if the maintainers/experts of timer.el (Kim?) get this mail, we
the users would appreciate some info on the timer-vector in the manual
or elsewhere :)

DG                                 http://deego.gnufans.org/~deego/
RMS on Treacherous Computing and Digital Restrictions Management ---

reply via email to

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