Re: idledo.el v. 0.3

[storm@cua.dk (Kim F. Storm)]

"D. Goel" <deego@gnufans.org> writes:

> Indeed.  Your proposal does cover all useful cases.  I like it!

Good.

> > 
> > Yes, it is true that with my proposal it is not possible to specify
> > an idle timer which is repeated while emacs remains idle, but does
> > not get repeated the next time emacs becomes idle --- but again, I
> > really don't see much use for that functionality either.
> 
> 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.  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.

> However, a user who does want to implement the "missing" functionality
> will again do weird stuff, as done in blink-cursor-mode and idledo.el.

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
would be called for the idle-timers which have been activated; for the
blinking cursor case it could be used (instead of the pre-command-hook)
to restore the visible cursor state.

> OTOH, the user can cleanly implement the missing functionality if one
> would provide one or more of the following variables.  (I guess one
> could also provide appropriate hooks instead of variables.)
> 
> idle-timer-idle-counter
>  "When running an idle-timer, this variable is (temporarily) bound to
>  the number of times the idle-timer has been triggered by emacs going idle.. "
> 
> idle-timer-repeat-counter
>  "when running an idle-timer, this variable is temporarily bound to
>  the number of times the idle-timer has been triggered , either by
>  emacs going idle, or by emacs remaining idle. "
> 

I'm not sure how these are useful in general, and I don't see why a
specific idle-timer which needs this information cannot implement them
locally [also, the information is currently not available anywhere].

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).

Or we could modify the basic timer implementation (it is currently an
8 element vector) by adding more elements to implement the various
features discussed above.  In any case, it cannot be done without some
changes to the interpretation of the fields of that vector, so it
might just as well be extended if that makes the implementation
simpler and cleaner.

WDYT ?  Is this something to pursue further, or should we be satisfied
with the current "work-arounds" ?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk