emacs-orgmode
[Top][All Lists]
Advanced

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

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


From: Eric Abrahamsen
Subject: Re: [O] Org-mode Habit with Varying Description
Date: Wed, 22 Oct 2014 00:29:45 +0800
User-agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux)

Samuel Loury <address@hidden> writes:

> Hi,
> Eric Abrahamsen <address@hidden> writes:
>
>> I've been (very gradually) working on something I'm calling org-log, for
>> just this sort of situation -- a library that would possibly go
>> underneath org-habit and maybe even org-clock. It would look like:
>>
>> * Read <book>
>>   :LOGBOOK:
>>   - Note taken on [2014-10-20 Mon 10:33] \\
>>     PAGES: 49
>>   - Note taken on [2014-10-20 Mon 10:32] \\
>>     PAGES: 150
>>   :END:
>>
>> When adding notes (or state-change log notes) the user would be prompted
>> to record values for the key(s) already existing in the logbook (in this
>> case, PAGES). Multiple key-value pairs would be possible. Generic tables
>> could be created for a heading, with more specialized tables with
>> user-defined column formulas and all that.
>>
>> Add unit manipulation/calculation from the calc-units package, and I
>> think this could be a nice extension to Org.
>>
>> I originally started thinking of this while translating a novel. I had a
>> certain number of characters to translate, and a certain deadline. What
>> I wanted was a single heading where I logged my progress, and a
>> reporting facility that said "given today's date and how many characters
>> you've already done, you'll need to average XXX characters per day to
>> hit the deadline." I envisioned a gnuplot table that showed
>> actual-characters-per-day against the shifting
>> average-characters-per-day.
>
> That is a very interesting idea. Do you think we could see your actual
> work?

Actual work?! Perhaps I gave the wrong impression :)

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.

I'm just thinking out loud -- I'm probably not the right one to make
this as useful as it can be. But I don't see any reason why we shouldn't
do this!

Eric




reply via email to

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