> 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.