Idleness

Idleness

[Hrvoje Niksic]

I noticed the code like this in gnus-util:

(defun gnus-demon-is-idle-p ()
  "Whether Emacs is idle or not."
  ;; We do this simply by comparing the 100 most recent keystrokes
  ;; with the ones we had last time.  If they are the same, one might
  ;; guess that Emacs is indeed idle.  This only makes sense if one
  ;; calls this function seldom -- like once a minute, which is what
  ;; we do here.
[...]

Why use these hacks, instead of the standard XEmacs IS-IDLE argument
to `start-itimer', or FSFmacs `run-with-idle-timer'?  Not that the
above hack doesn't work, but I just don't see the point...

Is it a compatibility thing?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
I'm sure they'll listen to reason! -- Neal Stevenson, _Snow Crash_

Re: Idleness

[Harald Meland]

[Hrvoje Niksic]

| I noticed the code like this in gnus-util:
| 
| (defun gnus-demon-is-idle-p ()
|   "Whether Emacs is idle or not."
|   ;; We do this simply by comparing the 100 most recent keystrokes
|   ;; with the ones we had last time.  If they are the same, one might
|   ;; guess that Emacs is indeed idle.  This only makes sense if one
|   ;; calls this function seldom -- like once a minute, which is what
|   ;; we do here.
| [...]
| 
| Why use these hacks, instead of the standard XEmacs IS-IDLE argument
| to `start-itimer', or FSFmacs `run-with-idle-timer'?  Not that the
| above hack doesn't work, but I just don't see the point...
| 
| Is it a compatibility thing?

No, I guess it has to do with the gnus-demon functionality of running
a function every N minutes _after_ emacs has been idle for X minutes.
`run-with-idle-timer' will only let you run a function every time
Emacs has been idle for SECS seconds, so using this would merely move
the hacking elsewhere, not remove it.

I don't know if the way XEmacs provides idle timers would make the
removal of the hack easy.
-- 
Harald

Re: Idleness

[Hrvoje Niksic]

Harald Meland <Harald.Meland@usit.uio.no> writes:

> | Why use these hacks, instead of the standard XEmacs IS-IDLE argument
> | to `start-itimer', or FSFmacs `run-with-idle-timer'?  Not that the
> | above hack doesn't work, but I just don't see the point...
> | 
> | Is it a compatibility thing?
> 
> No, I guess it has to do with the gnus-demon functionality of running
> a function every N minutes _after_ emacs has been idle for X minutes.
> `run-with-idle-timer' will only let you run a function every time
> Emacs has been idle for SECS seconds, so using this would merely move
> the hacking elsewhere, not remove it.

I don't see the difference between running a function every N seconds
_after_ Emacs has been idle, and running a function every time Emacs
has been idle for N seconds.  Could you please explain it to me?

> I don't know if the way XEmacs provides idle timers would make the
> removal of the hack easy.

XEmacs itimers provide a different interface to the same
functionality.  Internally, it works by comparing current time to the
`last-input-time'.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"A Real Programmer's code can awe with its fiendish brilliance, even
as its crockishness appalls."

Re: Idleness

[Hrvoje Niksic]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> >>>>> "Hrvoje" == Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> Hrvoje> I don't see the difference between running a function every N
> Hrvoje> seconds _after_ Emacs has been idle, and running a function every
> Hrvoje> time Emacs has been idle for N seconds.  Could you please explain
> Hrvoje> it to me?
> 
> In the first case the function will run repeatedly every N seconds,
> starting after Emacs has been idle for Y seconds.  In the second
> case the function will run once after Emacs has been idle for N
> seconds.

I see the difference now; thanks for the explanation.  But I must be
still missing something, because I don't yet understand why Gnus needs
the hack.  The FSFmacs `run-with-idle-timer' should behave as desired
when the REPEAT argument is nil:

    run-with-idle-timer is an interactive autoloaded Lisp function in `timer'.

    Perform an action the next time Emacs is idle for SECS seconds.
    If REPEAT is non-nil, do this each time Emacs is idle for SECS seconds.

The same goes for XEmacs' `start-itimer'...

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Ask not for whom the <CONTROL-G> tolls.

Re: Idleness

[Harald Meland]

[Hrvoje Niksic]

| I see the difference now; thanks for the explanation.  But I must be
| still missing something, because I don't yet understand why Gnus needs
| the hack.  The FSFmacs `run-with-idle-timer' should behave as desired
| when the REPEAT argument is nil:
| 
|     run-with-idle-timer is an interactive autoloaded Lisp function in `timer'.
| 
|     Perform an action the next time Emacs is idle for SECS seconds.
|     If REPEAT is non-nil, do this each time Emacs is idle for SECS seconds.

Read the documentation carefully.  I did earlier today, and discovered
that a non-nil REPEAT means that

	* the function will get run every time Emacs has gone from a
	non-idle state and remained in an idle state for SECS seconds,

whereas a nil REPEAT would imply that

	* the function is only called the very first time that Emacs
	goes from non-idle and stays idle for SECS seconds (i.e. the
	actual timer could very well be removed as soon as the
	function has been called (In fact, that may be the way it does
	work -- I haven't checked)).


That being said, if you think that

	* adding a repeating non-idle timer from the idle-timer
	function,
and
	* making sure the repeating non-idle timer gets removed as
	soon as Emacs becomes un-idle again

isn't a hack -- well, then we obviously have a different view of what
kind of code would make a hack :)
-- 
Harald

Re: Idleness

[Hrvoje Niksic]

Harald Meland <Harald.Meland@usit.uio.no> writes:

> That being said, if you think that
> 
> 	* adding a repeating non-idle timer from the idle-timer
> 	function, and
> 	* making sure the repeating non-idle timer gets removed as
> 	soon as Emacs becomes un-idle again
> 
> isn't a hack (...)

I think that:

	* adding a new idle timer from the idle-timer callback

is less of a hack.  I wonder if it would work correctly?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

Re: Idleness

[Hrvoje Niksic]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> With the hack you can have different values for N and Y, so Emacs
> can be idle for 10 minutes, then run a function every 1 minute or 1
> hour after that.  That is, if I correctly understand what the "hack"
> does.

I think the `itimer' interface in XEmacs supports this, because it
allows different integer values for VALUE and RESTART.  However,
changing the code so it works differently for different timer
libraries is probably not worth the trouble.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
The end of the world is coming...  SAVE YOUR BUFFERS!

Re: Idleness

[Harald Meland]

[Hrvoje Niksic]

| I think that:
| 
| 	* adding a new idle timer from the idle-timer callback
| 
| is less of a hack.  I wonder if it would work correctly?

I just did some simple testing, and it doesn't look like it would.  As
I noted in my previous mail, it appears that Emacs needs to go from a
non-idle state and remain idle for SECS seconds before FUNCTION is
called.

If you add an idle timer from the present idle timer FUNCTION, the new
FUNCTION will not get called before Emacs goes non-idle and then idle
again.

Of course you could add a non-idle timer, but this would have to check
whether Emacs has become non-idle every time it get's called, and I
can't find any way of determining that -- short of the present hack in
Gnus, and then we're back to square one, right?


BTW, here's the code I used for my testing.  Note that it will
positively break if the SECS argument used in the callback is larger
than the SECS argument in the separate `run-with-idle-timer' call, as
that would imply removing the spurious timer before it gets called.

(defvar harald-test-idle-timer-mother-timer nil)
(defvar harald-test-idle-timer-spurious-timer nil)

(defun harald-test-idle-timer-function ()
  (when harald-test-idle-timer-spurious-timer
    (cancel-timer harald-test-idle-timer-spurious-timer))
  (setq harald-test-idle-timer-spurious-timer
	(run-with-idle-timer 2 t 'harald-test-idle-timer-function))
  (message (current-time-string)))

(setq harald-test-idle-timer-mother-timer
      (run-with-idle-timer 5 t 'harald-test-idle-timer-function))
-- 
Harald