emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] A bit of work around org-clock-idle-time


From: Nick Dokos
Subject: Re: [O] A bit of work around org-clock-idle-time
Date: Wed, 18 Jul 2012 18:43:23 -0400

Nicolas Calderon <address@hidden> wrote:

> Hello,
> 
> I was trying to get org-clock-idle-time to work on my machine, but it
> would never kick in. Looking at the doc
> (http://orgmode.org/manual/Resolving-idle-time.html), I was left under
> the impression that x11idle was an option for a better experience, but
> emacs idle time would be used otherwise. After digging around a bit, I
> found out it was not the case. If you are using X, emacs WILL use
> x11idle, wether you have it or not, and in the latter case always get
> an idle time of 0.
> 
> From that, I have two patches to submit (next 2 emails):
> 
> I made a few modifications to x11idle itself. It seemed it could crash
> in many ways, one that was noted in comments but somehow not averted
> by the addition of a if. I added a few more checks, and made it return
> more meaningful error codes (more on that later).
> 
> 
> Since org-mode doesn't depend on x11idle being installed on the
> machine (at least not on debian), I thought it could be interesting to
> add a few checks. First of all, I make sure that the command exists (I
> used this post to do it the most generic way,
> http://stackoverflow.com/questions/592620/check-if-a-program-exists-from-a-bash-script),
> and then, that the command can execute properly (can connect to the
> display, there is enough memory for the info struct and the reporting
> of idle time is supported). I'm not sure this is the best
> implementation (how often does this get called? If it's often, it
> might be worth caching the results rather than invoking two shell
> commands every time), but that's as good as I could do with my
> knowledge of lisp (none, as of before looking into this).
> 
> Hopefully, all this will respect what I read here:
> http://orgmode.org/worg/org-contribute.html.
> 

Fixing these problems is a good idea, but I have some comments on your
fixes:


o The x11idle.c fixes have whitespace problems, there is an
  unnecessary (badly named *and* misspelled) variable introduced[fn:1]
  and, at least on my (64-bit) platform the %u format causes the
  compiler to complain: it needs to be %lu in my case. This last is of
  course an original problem, not a problem that you introduced, but if
  you are going to fix things, maybe it should be fixed as well, but I'm
  not sure whether %lu is OK on a 32-bit system - can somebody check?

o in org-clock.el, instead of checking whether x11idle exists or not, how
  about something like this:

  ...
  (eq window-system 'x)
     (max (org-x11-idle-seconds) (org-emacs-idle-seconds))
  ...
  
  This is no worse than it is today as far as efficiency goes, but in any
  case, it's not so much the inefficiency of calling out to the shell that I
  object to, it's more the unnecessary complications added to the code.
  Also, it is easy to memoize org-x11-idle-seconds so that it doesn't call
  out to the shell every time, if that seems desirable, but that can be deferred
  for later.


Thanks for finding and fixing the problems: I wouldn't have looked if
you hadn't pointed the way! Hope the comments are useful.

Nick


Footnotes:

[fn:1] I'm talking about "querry" - you can leave it out altogether:

    ...
    //X11 is running, try to retrieve info
    if (XScreenSaverQueryInfo(display, DefaultRootWindow(display), info) == 0) {
        return -1;
    }

    //info was retrieved successfully, print idle time
    printf("%lu\n", info->idle);
    ...

    will do just as well.



reply via email to

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