[O] A bit of work around org-clock-idle-time
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. Thanks, -- Nicolas Calderon
[O] Patch for x11idle
>From c4856a35a2118efb16d6b8eb674ff9e05fc7f65a Mon Sep 17 00:00:00 2001
From: Nicolas Calderon Asselin
Date: Wed, 18 Jul 2012 14:19:10 -0400
Subject: [PATCH 1/2] Made x11idle more robust
* UTILITIES/x11idle.c (org-clock-idle-time): Added multiple checks to
functions return values to prevent segfault. Also "fixed" return codes
to fail unless the value could be printed, in which case the program
succeeds.
TINYCHANGE
---
UTILITIES/x11idle.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/UTILITIES/x11idle.c b/UTILITIES/x11idle.c
index 33d0035..8d54468 100644
--- a/UTILITIES/x11idle.c
+++ b/UTILITIES/x11idle.c
@@ -8,14 +8,25 @@
* path
*/
main() {
+Status querry = 0;
XScreenSaverInfo *info = XScreenSaverAllocInfo();
+//open the display specified by the DISPLAY environment variable
Display *display = XOpenDisplay(0);
-//check that X11 is running or else you get a segafult/coredump
-if (display != NULL) {
- XScreenSaverQueryInfo(display, DefaultRootWindow(display), info);
+//display could be null if there is no X server running
+if (info == NULL || display == NULL) {
+return -1;
}
-XScreenSaverQueryInfo(display, DefaultRootWindow(display), info);
+
+//X11 is running, retrieve and print idle time
+ querry = XScreenSaverQueryInfo(display, DefaultRootWindow(display),
info);
+
+if (querry == 0) {
+return -1;
+}
+
+//idle time was retrieved successfully, print it
printf("%u\n", info->idle);
return 0;
}
+
--
1.7.10.4
[O] Patch for org-clock.el
>From c8979b360749ecd66e298fdbdbc2450668be3a20 Mon Sep 17 00:00:00 2001 From: Nicolas Calderon Asselin Date: Wed, 18 Jul 2012 14:58:31 -0400 Subject: [PATCH 2/2] Added checks to determine which idle time to use * lisp/org-clock.el (org-clock-idle-time): Org-mode assumed that x11idle was an available command, and returned an idle time of 0 if it was not (never idle). Added checks so that org-idle-time will come from emacs' own current-idle-time if x11idle cannot be found or if it cannot retrieve the idle time from X11 TINYCHANGE --- lisp/org-clock.el |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 162ee07..a913014 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -1010,7 +1010,12 @@ This routine returns a floating point number." (cond ((eq system-type 'darwin) (org-mac-idle-seconds)) - ((eq window-system 'x) + ((and + (eq window-system 'x) + ;; Check that x11idle exists + (eq (call-process-shell-command "command" nil nil nil "-v" "x11idle") 0) + ;; Check that x11idle can retrieve the idle time + (eq (call-process-shell-command "x11idle" nil nil nil ) 0)) (org-x11-idle-seconds)) (t (org-emacs-idle-seconds -- 1.7.10.4
Re: [O] A bit of work around org-clock-idle-time
Sorry, I forgot to reply to all when Nicolas D. answered the first email and took it off the list. Here is what you missed regarding org-clock.el: On Thu, Jul 19, 2012 at 2:33 PM, Nick Dokos wrote: > Nicolas Calderon wrote: > >> >> As for the max solution for idle time, I don't think it's a good >> solution. It solves the case where x11idle always return 0, but if >> you're active in X (x11idle always low) but not in emacs (high idle >> time), you'll end up in clock resolving mode. >> > > Fair enough, but it can still be done so as to simulate today's behavior > while avoiding the 0 case. Something like > > ((eq window-system 'x) > (let ((idle (org-x11-idle-seconds))) > (if (> idle 0) > idle > (org-emacs-idle-seconds The problem I see here is that 0 is a valid output for x11idle, so if the check is done while X11 is not idle, it will fall back to org-emacs-idle-seconds. From what I could see in the shell-command-to-string, there is no way to tell between an output from the program and the 0 the function returns if there is no output (can't find the command). That's why I added the additional check for the command existence. Optimally, that check would be done once at startup or the first time idle time is checked but I lack the elisp skills to perform such a "feat". That being said, the patch was merged in, so I don't know if it's an indication that I should not worry. Thanks, -- Nicolas Calderon On Fri, Jul 27, 2012 at 11:19 PM, Nick Dokos wrote: > Bastien wrote: > >> Nick Dokos writes: >> >> > 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)) >> > ... >> >> Yes, this is cleaner, thanks! >> > > Cleaner maybe, but it's not correct, as Nicolas C. pointed out. Nicolas > C. and I had an email exchange and I hope he will follow up with revised > patches. > > Nick
[O] Properties drawer
Hi, I'm currently using the org-treat-insert-todo-heading-as-state-change and I log state changes, which means that when I create a heading it automatically inserts a logbook drawer. I like to keep my property drawers near the heading, but their position doesn't seem to be anchored as tags are. After entering my heading, if I press RET, I end up pushing the drawers further down and inserting text between the heading and the drawers. I also try to assign ids from the get go, for further referencing, so I have 2 drawers (logbook and properties). Skipping all that and inserting text after is a bit annoying. Is there an easy way to ensure the drawers always stay nicely tucked under the headings? I'm looking for something like whatever keeps the tags in place no matter what. Thanks, -- Nicolas Calderon Asselin
