[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: idledo.el v. 0.3
D . Goel
Re: idledo.el v. 0.3
24 Oct 2002 10:25:39 -0400
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
> 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
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 :)
RMS on Treacherous Computing and Digital Restrictions Management ---
Re: idledo.el v. 0.3, Richard Stallman, 2002/10/25