From mboxrd@z Thu Jan 1 00:00:00 1970 From: Noah Slater Subject: Re: Filtering org-clock-display Date: Sun, 20 Apr 2014 12:52:21 +0200 Message-ID: References: <871twsjnzz.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf303a32d560d9e404f7772db5 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60101) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WbpMK-00048C-SQ for emacs-orgmode@gnu.org; Sun, 20 Apr 2014 06:52:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WbpME-0000t7-DB for emacs-orgmode@gnu.org; Sun, 20 Apr 2014 06:52:28 -0400 Received: from mail-yh0-x22c.google.com ([2607:f8b0:4002:c01::22c]:48757) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WbpME-0000sv-7H for emacs-orgmode@gnu.org; Sun, 20 Apr 2014 06:52:22 -0400 Received: by mail-yh0-f44.google.com with SMTP id f10so2744651yha.17 for ; Sun, 20 Apr 2014 03:52:21 -0700 (PDT) In-Reply-To: <871twsjnzz.fsf@bzg.ath.cx> 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: Bastien Cc: emacs-orgmode@gnu.org --20cf303a32d560d9e404f7772db5 Content-Type: text/plain; charset=ISO-8859-1 I suppose, in a way, blurring the line between org-clock-display and clocktables is what I am trying to do. I think org-clock-display is much more useful and easier to use. (Though I don't doubt that clocktables work better for some folks.) I started out with clocktables, but I found it clumsy to be checking my clock times in one location, and then clocking times in another location. This is true even when the clocktable is in the same file as the nodes. Bit of context: I'm clock times for my own benefit, not for a client. My primary concern is time allocation. i.e. Making sure that each of the areas I clock under receives an appropriate amount of attention. Old workflow: - Jump to the top of the file or to the index file with my clocktable - Refresh the clocktable - Sort the clocktable by time - Scan the table for the next area that needs my attention - Either activate the link or manually find the corresponding node - Clock on to that node Note: sorting the clock table doesn't work very well. I want each level to be sorted recursively. New (and preferred) workflow: - Sort nodes recursively (thanks Sacha!) - org-overview - org-clock-display - Drill down into the area I that needs the most attention - Clock on to that node In this second workflow, notice that: - Sorting works (because it can be done recursively, either manually as you expand each node, or with a recursive function) - The data (i.e. clocked time) is available *in situ* as I navigate around the file Wrt the laziness remark :) I am happy to write patches. On 20 April 2014 12:26, Bastien wrote: > Noah Slater writes: > > > What do others think about this idea? > > I welcome feedback on this but let's take care not to overengineer > this: if we add to many features to `org-clock-display', it will blur > the line between this temporary display and clock tables. > > I would first try using temporary clock tables then see if the feature > is still need for org-clock-display. > > Just my 2cts of lets-pretend-laziness-is-carefulness, of course, > > -- > Bastien > --20cf303a32d560d9e404f7772db5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I suppose, in a way, blurring the line between org-cl= ock-display and clocktables is what I am trying to do. I think org-clock-di= splay is much more useful and easier to use. (Though I don't doubt that= clocktables work better for some folks.)

I started out with clocktables, but I found it clumsy to be = checking my clock times in one location, and then clocking times in another= location. This is true even when the clocktable is in the same file as the= nodes.

Bit of context: I'm clock times for my own benefit, not = for a client. My primary concern is time allocation. i.e. Making sure that = each of the areas I clock under receives an appropriate amount of attention= .

Old workflow:

- Jump to the to= p of the file or to the index file with my clocktable
- Refresh t= he clocktable
- Sort the clocktable by time
- Scan the = table for the next area that needs my attention
- Either activate the link or manually find the corresponding node
- Clock on to that node

Note: sorting the c= lock table doesn't work very well. I want each level to be sorted recur= sively.

New (and preferred) workflow:

= - Sort nodes recursively (thanks Sacha!)
- org-overview
- org-clock-display
- Drill down into the area I that needs = the most attention
- Clock on to that node

In this second workfl= ow, notice that:

- Sorting works (because it can b= e done recursively, either manually as you expand each node, or with a recu= rsive function)
- The data (i.e. clocked time) is available *in situ* as I navigate ar= ound the file

Wrt the laziness remark :) I am happ= y to write patches.



On 20 April 2014 12:26, Bastien <bzg@gnu.org<= /a>> wrote:
Noah Slater <nsl= ater@tumbolia.org> writes:

> What do others think about this idea?

I welcome feedback on this but let's take care not to overenginee= r
this: if we add to many features to `org-clock-display', it will blur the line between this temporary display and clock tables.

I would first try using temporary clock tables then see if the feature
is still need for org-clock-display.

Just my 2cts of lets-pretend-laziness-is-carefulness, of course,

--
=A0Bastien

--20cf303a32d560d9e404f7772db5--