From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Abrahamsen Subject: Re: Org-mode Habit with Varying Description Date: Wed, 22 Oct 2014 00:29:45 +0800 Message-ID: <87zjcpfksm.fsf@ericabrahamsen.net> References: <87ppdmfxre.fsf@enterprise.sectorq.net> <87zjcqz2f2.fsf@ericabrahamsen.net> <87egu1zk8k.fsf@konixwork.incubateur.ens-lyon.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34067) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgcFM-0003QD-OB for emacs-orgmode@gnu.org; Tue, 21 Oct 2014 12:25:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XgcFG-00032S-JR for emacs-orgmode@gnu.org; Tue, 21 Oct 2014 12:25:20 -0400 Received: from plane.gmane.org ([80.91.229.3]:41629) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgcFG-000324-Cv for emacs-orgmode@gnu.org; Tue, 21 Oct 2014 12:25:14 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XgcFD-0006aC-44 for emacs-orgmode@gnu.org; Tue, 21 Oct 2014 18:25:11 +0200 Received: from 111.199.149.147 ([111.199.149.147]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 21 Oct 2014 18:25:11 +0200 Received: from eric by 111.199.149.147 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 21 Oct 2014 18:25:11 +0200 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 Samuel Loury writes: > Hi, > Eric Abrahamsen 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 >> :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