From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcin Borkowski Subject: Re: Tracking time from one state to another? Date: Fri, 19 Apr 2019 06:37:42 +0200 Message-ID: <87lg06hap5.fsf@mbork.pl> References: <868sw8n7qm.fsf@gmail.com> <878sw7ix52.fsf@mbork.pl> <86zhoncop2.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([209.51.188.92]:44199) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHLKk-0004kU-BI for emacs-orgmode@gnu.org; Fri, 19 Apr 2019 00:41:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hHLJB-0007lf-33 for emacs-orgmode@gnu.org; Fri, 19 Apr 2019 00:39:30 -0400 Received: from mail.mojserwer.eu ([195.110.48.8]:54774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHLJA-0007gm-P7 for emacs-orgmode@gnu.org; Fri, 19 Apr 2019 00:39:29 -0400 In-reply-to: <86zhoncop2.fsf@gmail.com> 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" To: Malcolm Matalka Cc: emacs-orgmode@gnu.org On 2019-04-18, at 17:34, Malcolm Matalka wrote: > Marcin Borkowski writes: > >> On 2019-04-17, at 14:20, Malcolm Matalka wrote: >> >>> Hello, >>> >>> Is it possible in org-mode to track, and report, the duration of certain >>> state transitions in org-mode? In particular, I'm interested in >>> tracking how long it takes me to go from a state that means I'm actively >>> working on an item to it being in a done state? >>> >>> In my case, an item might go from working, to waiting, to working, to >>> done. And in this case I'm only really interested in the last working >>> to done time. >>> >>> For my case, I'm looking to do a weekly report on how long it takes me >>> to complete tasks that I have said I will work on. >> >> Hi Malcolm, >> >> that sounds interesting. Since you can turn on logging of state changes >> (as you probably know), this is in principle possible, though I don't >> think it is built in. >> >> I guess writing a bit of Elisp to accomplish this should not be very >> difficult, though it seems that currently the problem is a bit >> underspecified. If you could elaborate, e.g., provide an example of >> your state change log and describe the result you would like to get, >> I could be tempted to coding this. >> >> Best, > > Sure! > > So for my use case, I'm mostly interested in the last transition to a > finished state, but for simplicity I'll specify the two states I'm > interested in: > > Given states NEXT and DONE, I want to know the time between going into > NEXT and over to DONE. > > For example, given the following logbook: > > :LOGBOOK: > - State "DONE" from "NEXT" [2019-04-01 Mon 11:07] > - State "NEXT" from "TODO" [2019-04-01 Mon 10:35] > - State "NEXT" from "TODO" [2018-07-02 Mon 11:03] > :END: > > > This item would be 32 minutes. > > This one: > > :LOGBOOK: > - State "DONE" from "NEXT" [2019-04-10 Wed 09:56] > - State "NEXT" from "WAITING" [2019-04-10 Wed 09:40] > - State "WAITING" from "NEXT" [2019-04-09 Tue 10:44] > - State "NEXT" from "WAITING" [2019-04-09 Tue 10:10] > - State "WAITING" from "NEXT" [2019-04-08 Mon 16:39] > - State "NEXT" from "TODO" [2019-04-08 Mon 11:14] > :END: > > > Would be 16 minutes. Are those :LOGBOOK: drawers real? They are not sorted chronologically, as they probably should be (though I'm not sure, I don't se them much). > I'd like to specify what time range to do this for, and be able to sort > by duration. > > I think a dynamic block, like clocktable, would probably be a fine. > > Any idea what the level of work involved is to accomplish this? I'm > guessing a very hacky version might be to modify clock table and look at > the logbook instead of clock and filter out all but the last transition? I don't think that's the best way - Org-mode code is famously complicated, it might be easier to do it from scratch (it'd be perhaps less general then, though). Anyway, it doesn't look like a lot of work - an hour or two for a rough prototype might be enough. > Also, this is just the usecase I'm interested in, so if you have > thoughts on what a more general form would look like, that would be interested. No idea yet. Best, -- Marcin Borkowski http://mbork.pl