From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Abrahamsen Subject: Re: Org-mode Habit with Varying Description Date: Sun, 26 Oct 2014 08:51:16 -0700 Message-ID: <87tx2q7rt7.fsf@ericabrahamsen.net> References: <87ppdmfxre.fsf@enterprise.sectorq.net> <87zjcqz2f2.fsf@ericabrahamsen.net> <87egu1zk8k.fsf@konixwork.incubateur.ens-lyon.fr> <87zjcpfksm.fsf@ericabrahamsen.net> <878uk6nng6.fsf@enterprise.sectorq.net> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42604) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiQ1a-00088K-Mk for emacs-orgmode@gnu.org; Sun, 26 Oct 2014 11:46:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XiQ1T-0004xA-4P for emacs-orgmode@gnu.org; Sun, 26 Oct 2014 11:46:34 -0400 Received: from plane.gmane.org ([80.91.229.3]:46244) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiQ1S-0004wy-Tr for emacs-orgmode@gnu.org; Sun, 26 Oct 2014 11:46:27 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XiQ1R-00026n-In for emacs-orgmode@gnu.org; Sun, 26 Oct 2014 16:46:25 +0100 Received: from 63.226.249.211 ([63.226.249.211]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 26 Oct 2014 16:46:25 +0100 Received: from eric by 63.226.249.211 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 26 Oct 2014 16:46:25 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Pete Ley writes: >> All I've got now are a function that finds the logbook, and another that >> parses the log items and normalizes them: extracts the TODO >> states/timestamps/key-values and sets them as properties on the items >> themselves. Then you've got a pretty good basis from which to do >> reporting. >> >> Hooking into note-taking and todo state-change logging to prompt for >> values should be easy. >> >> I don't know yet how to approach the reporting part, mostly because I >> haven't sat down and thought about how this would be most useful. It >> will also require reading org-clock and org-habit in detail -- clearly >> reporting to a table like they do is the right way to go. >> >> How to get the most out of the data? I was thinking of having >> COLUMN_FORMULA and TABLE_FORMULA properties on the heading. When you >> report from the heading, each key in the logbook data creates a table >> column. Each column formula property creates another column, populated >> by that formula (presumably calculated from the data columns). Then the >> table formula gets slapped on to the bottom of it, and the whole thing >> runs. >> >> So if you had a heading like this: >> >> * TODO Anneal galoshes >> :LOGBOOK: >> GALOSHES: 15; CLOCK: [2014-10-15 Wed 09:07]--[2014-10-15 Wed 17:10] => 8:03 >> GALOSHES: 13; CLOCK: [2014-10-14 Tue 08:50]--[2014-10-14 Tue 16:30] => 7:40 >> GALOSHES: 14; CLOCK: [2014-10-13 Mon 09:30]--[2014-10-13 Mon 17:06] => 7:36 >> :END: >> >> You'd end up with a table with two data columns. Then you could have a >> COLUMN_FORMULA property that created a third column, displaying galoshes >> annealed per hour. And a TABLE_FORMULA property that did... something... >> with all that information. >> >> In a sense, it's a bit like column view, except using logbook data >> rather than property values. > > This sounds pretty great. I'd like to see the functions you have anyway, > seems like something the community might find useful. I know I could > find a few use cases for it. Hmm, the underlying code has changed since I started working on this. Nicolas, can I ask your advice here? I need to rewrite an earlier function which returned a heading's log list, or returned nil. I'd be happy with a function that returned the starting point of the log list, or nil. Right now it looks like the central "cond" statement in `org-add-log-setup' is as close as we've got to a canonical definition of where a heading's log list is to be found. Should I just write my own version of this, or would you be open to refactoring `org-add-log-setup' so the "finding" part is a separate function that can be reused elsewhere? Thanks, Eric