From: Noah Slater <email@example.com>
To: Bastien <firstname.lastname@example.org>
Subject: Re: Filtering org-clock-display
Date: Sun, 20 Apr 2014 12:52:21 +0200 [thread overview]
Message-ID: <CA+Y+445JrtBVu-TbGhHu7WAqC0+BvPggAxYs1+U+VwAceCKsOA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2107 bytes --]
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.
- 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!)
- 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
Wrt the laziness remark :) I am happy to write patches.
On 20 April 2014 12:26, Bastien <email@example.com> wrote:
> Noah Slater <firstname.lastname@example.org> 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,
[-- Attachment #2: Type: text/html, Size: 2968 bytes --]
next prev parent reply other threads:[~2014-04-20 10:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-20 9:25 Filtering org-clock-display Noah Slater
2014-04-20 10:26 ` Bastien
2014-04-20 10:52 ` Noah Slater [this message]
2014-04-20 13:18 ` Bastien
2014-05-24 18:25 ` Noah Slater
2014-05-25 5:26 ` Bastien
2014-05-25 19:47 ` Noah Slater
2014-05-26 5:14 ` Bastien
2014-05-26 15:35 ` Noah Slater
2014-05-30 12:15 ` Bastien
2014-05-31 13:36 ` Noah Slater
2014-05-31 14:48 ` Bastien
2014-05-31 21:36 ` Noah Slater
2014-07-28 15:45 ` Bastien
2014-08-05 14:51 ` Noah Slater
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).