Re: [O] Org-mode Habit with Varying Description

[Eric Abrahamsen]

Pete Ley <address@hidden> 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