Re: idledo.el v. 0.3

Re: idledo.el v. 0.3

[D. Goel]

storm@cua.dk (Kim F. Storm) writes:
> 
> If you look at run-with-timer, the REPEAT parameter may be an
> integer/float indicating a repeat period for the timer, while for
> run-with-idle-timer, repeat is just a boolean.
> 
> IMO, the clean enhancement to timer.el would be to allow REPEAT to be
> a number for run-with-idle-timer as well.


run-with-idle-timer (secs repeat function &rest args)

Current functionality:

 If REPEAT is non-nil, do the action each time Emacs has been idle for
 exactly SECS seconds (that is, only once for each time Emacs becomes idle).


Are you suggesting instead that:
(1)
 If REPEAT is t, do the action each time Emacs has been idle for
 exactly SECS seconds (that is, only once for each time Emacs becomes idle).
 
 It REPEAT is a number, keep repeating the action for REPEAT seconds
 as long as emacs remains idle.  

or that:
(2)
 If REPEAT is t, do the action each time Emacs has been idle for
 exactly SECS seconds (that is, only once for each time Emacs becomes idle).

 If REPEAT is a number, do the action each time Emacs has been idle
 for exactly REPEAT seconds (that is, only once for each time Emacs
 becomes idle).
?


The second one makes more sense to me, since REPEAT in
run-with-idle-timer deals not with repeat-while-idle but with
REPEAT-when-next-idle... OTOH, the first one would (incompletely) mix
the 2 different booleans/numbers into one REPEAT..



(Of course, if the seocnd option is what happens, or if none of the
two happen, we still haven't provided the functionality of 'repeating
as long as emacs remains' idle..

for which one could have new function named as, say run-while-idle-timer. )

PS: run-with-idle-timer indeed has more "degrees of freedom" than does
"run-with-timer"...



DG                                 http://deego.gnufans.org/~deego/
--

Re: idledo.el v. 0.3

[Kim F. Storm]

I wrote to D. Goel:
> I would suggest handling the timer directly in idledo to
> remove the dependency of timerfunctions.el
> 

"D. Goel" <deego@gnufans.org> writes:
> RMS once suggested that i merge the functionality of timerfunctions.el
> into timer.el 
> 
> I guess once the basic function 'tf-run-with-idle-timer' of
> timerfunctions.el becomes "right", we could rename it to some
> appropriate name liek 'run-while-idle-timer' and make that function
> part of timer.el if people agree...

If you look at run-with-timer, the REPEAT parameter may be an
integer/float indicating a repeat period for the timer, while for
run-with-idle-timer, repeat is just a boolean.

IMO, the clean enhancement to timer.el would be to allow REPEAT to be
a number for run-with-idle-timer as well.

This requires C-level changes, e.g. using the first element of the
timer vector to store the next time to execute the idle timer..., as
well as changes to timer-event-handler to update that field, but I
think it would be fairly trivial.

Once this is in place, we can also simplify the implementation of the
blink-cursor-mode.

WDYT?

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

Re: idledo.el v. 0.3

[D. Goel]

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

> 
> or that:
> (2)
>  If REPEAT is t, do the action each time Emacs has been idle for
>  exactly SECS seconds (that is, only once for each time Emacs becomes idle).
> 
>  If REPEAT is a number, do the action each time Emacs has been idle
		
	Err...            do the *subsequent* action..

 (because the very first action takes place after SECS seocnds, of course..)

Re: idledo.el v. 0.3

[Kim F. Storm]

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

> run-with-idle-timer (secs repeat function &rest args)
> 
> Current functionality:
> 
>  If REPEAT is non-nil, do the action each time Emacs has been idle for
>  exactly SECS seconds (that is, only once for each time Emacs becomes idle).
> 
> 
> Are you suggesting instead that:
> (1)
> [...]

(1) almost described what I had in mind:

  If REPEAT is non-nil, do the action each time Emacs has been idle
  for exactly SECS seconds.
  
  If REPEAT is a number, keep repeating the action every REPEAT
  seconds as long as emacs remains idle; otherise, only do the action
  once for each time Emacs becomes idle.


> or that:
> (2)
>  If REPEAT is t, do the action each time Emacs has been idle for
>  exactly SECS seconds (that is, only once for each time Emacs becomes idle).
> 
>  If REPEAT is a number, do the subsequent action each time Emacs has been idle
>  for exactly REPEAT seconds (that is, only once for each time Emacs
>  becomes idle).
> ?
> 
> 
> The second one makes more sense to me, since REPEAT in
> run-with-idle-timer deals not with repeat-while-idle but with
> REPEAT-when-next-idle...

Yes, formally it makes more sense, but I cannot see any purpose for that
functionality -- whereas the proposed functionality is definitely useful!


> OTOH, the first one would (incompletely) mix
> the 2 different booleans/numbers into one REPEAT..

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.

So although the proposed "overloading" of the REPEAT argument for
run-with-idle-timer does not cover every possible combination, I think
it covers all the practical functions (in all cases the action is first
executed SECS seconds after emacs becomes idle):

- not repeating the idle action at all (REPEAT = nil)
- repeating (once) every time emacs becomes idle (REPEAT = t)
- repeating every time emacs becomes idle, and then every REPEAT
  seconds while emacs remains idle (REPEAT = number)  


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

Re: idledo.el v. 0.3

[D. Goel]

storm@cua.dk (Kim F. Storm) writes:
>(1)
>   If REPEAT is non-nil, do the action each time Emacs has been idle
>   for exactly SECS seconds.
>   
>   If REPEAT is a number, keep repeating the action every REPEAT
>   seconds as long as emacs remains idle; otherise, only do the action
>   once for each time Emacs becomes idle.

> So although the proposed "overloading" of the REPEAT argument for
> run-with-idle-timer does not cover every possible combination, I think
> it covers all the practical functions (in all cases the action is first
> executed SECS seconds after emacs becomes idle):
> 
> - not repeating the idle action at all (REPEAT = nil)
> - repeating (once) every time emacs becomes idle (REPEAT = t)
> - repeating every time emacs becomes idle, and then every REPEAT
>   seconds while emacs remains idle (REPEAT = number)  
> 


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



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

Moreover, providing additional arguments to cover this "missing"
situation would break the backward compatibility of
run-with-idle-timer.  So, this user seconds your proposal!

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






DG                                 http://deego.gnufans.org/~deego/
--

Re: idledo.el v. 0.3

[D. Goel]

storm@cua.dk (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

Indeed.


> 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;

Exactly. 

> 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 ---
http://newsforge.com/newsforge/02/10/21/1449250.shtml?tid=19

Re: idledo.el v. 0.3

[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

Re: idledo.el v. 0.3

[Richard Stallman]

    IMO, the clean enhancement to timer.el would be to allow REPEAT to be
    a number for run-with-idle-timer as well.

    This requires C-level changes, e.g. using the first element of the

I think this feature can be implemented at the Lisp level, in
timer.el.

Re: idledo.el v. 0.3

[Richard Stallman]

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

On the contrary, the awkward thing would be to put that in--awkward
and useless.  Let's not complicate the interface to support a case
that people do not need.

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

Let's not add these.  There isno reason to think they are needed.

If we add features merely for completeness we would have twice as many
of them.  So our policy in maintaining Emacs is not to add features
merely for completeness.  We only add the features that are actually
needed.

Re: idledo.el v. 0.3

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     IMO, the clean enhancement to timer.el would be to allow REPEAT to be
>     a number for run-with-idle-timer as well.
> 
>     This requires C-level changes, e.g. using the first element of the
> 
> I think this feature can be implemented at the Lisp level, in
> timer.el.

If we want this to be supported directly in the idle-timers (not
having to setup an idle-timer or a pre-command-hook), it requires C
level changes!

But I agree that it can [and should] be done in lisp [in a way similar
to what blink-cursor-mode currently does].

So I suggest the following to changes to timer.el:

Change run-with-idle-timer so that:

  If REPEAT is non-nil, do the action each time Emacs has been idle
  for exactly SECS seconds.
  
  If REPEAT is a number, keep repeating the action every REPEAT
  seconds as long as emacs remains idle; otherwise, only do the action
  once for each time Emacs becomes idle.

[Implementation: use a list of normal timers (one for each repeating
 idle hook) similar to blink-cursor-mode, and a pre-command hook which
 clears that list when emacs is no longer idle].


Add a new function:

  (timer-idle-timer-first-invocation-p TIMER)

which allows an idle-timer action to check whether this is the first
invocation of the timer after emacs becoming idle, or a repeated
activation.

[Implementation: just look at the first element of the timer vector]


Add a new hooks:

  timer-no-longer-idle-hook

where users of idle-timers may setup functions to be called when emacs
is no longer idle.  Functions may be added/removed to this hook once
(e.g. when blink-cursor-mode is turned on or off), or it could be
added by the idle-timer action (in which case the hook function would be
responsible for removing the function from the hook when called).

Note: Globally added functions on that hook are called independently
of whether the "corresponding" idle-timer was activated or not (there
is really no way to associate the function with a specific timer;
however, they can use the timer-idle-timer-first-invocation-p function
to check whether a specific timer has been activated)

[Implementation: Run from the above mentioned pre-command hook.]

Note: The pre-command hook is only setup when the first idle-timer is
activated, so if no idle-timers have been activated, the
timer-no-longer-idle-hook isn't run either!  

[This may seem a little strange, but from a practical point of view, I
think it actually makes good sense, as the intended purpose of the
no-longer-idle hook is to be able to clean-up things which were
initiated by an idle-timer action.  So if no idle-timers were run,
there's no reason to run the hook either].


As an example, blink-cursor-mode could then be implemented by just three
functions:

(defun blink-cursor-mode (arg)
   ... e.g. to turn it on ...:
    (setq blink-cursor-idle-timer
	(run-with-idle-timer
            blink-cursor-delay
            blink-cursor-interval  ;; OBS: New functionality!!!
            'blink-cursor-blink))
    (add-hook 'timer-no-longer-idle-hook 'blink-cursor-stop))

(defun blink-cursor-blink ()
  "Toggle blinking cursor."
  (internal-show-cursor nil (not (internal-show-cursor-p))))

(defun blink-cursor-stop ()
  "Stop cursor blinking."
  (internal-show-cursor nil t))

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

Re: idledo.el v. 0.3

[Richard Stallman]

    Add a new function:

      (timer-idle-timer-first-invocation-p TIMER)

    which allows an idle-timer action to check whether this is the first
    invocation of the timer after emacs becoming idle, or a repeated
    activation.

Is there an actual need for this, or just a theoretical need?  You
could do it easily enough by setting a flag variable when the timer
runs, and clearing it using timer-no-longer-idle-hook.

    Add a new hooks:

      timer-no-longer-idle-hook

    [Implementation: Run from the above mentioned pre-command hook.]

This is a useful feature, but why not use pre-command-hook directly?

Re: idledo.el v. 0.3

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Add a new function:
> 
>       (timer-idle-timer-first-invocation-p TIMER)
> 
>     which allows an idle-timer action to check whether this is the first
>     invocation of the timer after emacs becoming idle, or a repeated
>     activation.
> 
> Is there an actual need for this, or just a theoretical need?  You
> could do it easily enough by setting a flag variable when the timer
> runs, and clearing it using timer-no-longer-idle-hook.

True, it is strictly not needed, since the hook can use a boolean to
know whether it was repeated (or activated at all)...  However, since
that information which is already recorded in the timer vector, it
seemed natural (and friendly :-) to give the hook easy access to that
information.

> 
>     Add a new hooks:
> 
>       timer-no-longer-idle-hook
> 
>     [Implementation: Run from the above mentioned pre-command hook.]
> 
> This is a useful feature, but why not use pre-command-hook directly?

Because the pre-command-hook is called for all command - also when
emacs hasn't been idle; that seems highly wasteful to me.

I'll make a patch for the proposed features; then you can see how much
of that you want me to install.

Re: idledo.el v. 0.3

[Richard Stallman]

    > This is a useful feature, but why not use pre-command-hook directly?

    Because the pre-command-hook is called for all command - also when
    emacs hasn't been idle; that seems highly wasteful to me.

timer-no-longer-idle-hook would be added complexity and a possible
optimization.  So the question is, how much slowdown does it avoid?
Is the optimization sufficient to be worth one more feature?