From: Erik Iverson <eriki@ccbr.umn.edu>
Cc: emacs-orgmode@gnu.org
Subject: Re: Re: Clock report (R from the agenda)
Date: Fri, 19 Nov 2010 12:38:58 -0600 [thread overview]
Message-ID: <4CE6C442.3030201@ccbr.umn.edu> (raw)
In-Reply-To: <80tyjdl89g.fsf@mundaneum.com>
I don't know what this thread is about, but it seems related.
Aapologies if I'm
hijacking it, but as of my latest pull just this morning,
my agenda has no clocktable in it, where as it previously
did. I have not changed anything as far as I know.
Thanks!
--Erik
Sébastien Vauban wrote:
> Hi Carsten,
>
> Carsten Dominik wrote:
>> On Nov 4, 2010, at 11:39 AM, Sébastien Vauban wrote:
>>> Carsten Dominik wrote:
>>>> you should now be able to use `C-u R' to achieve this.
>>> OK.
>>>
>>>
>>>> The lighter in the mode line will then switch from "Clock" to "Clock{}",
>>> A detail: I'd eventually would have written "Clock/" to remind the "/" used
>>> for applying the filters.
>> I did use {} because the current filter is actually listed in the mode line,
>> surrounded by {}.
>>
>>> Another: could we append, in the modeline, the tags (or their abbrev, such
>>> as "w" for "work") used in the filtered view?
>> The filter *is* shown in the mode line. Just not as part of the Clock
>> lighter.
>
> I wanted to (re-)test these, but now, when doing R, nothing is appended into
> my buffer with logged times. Did I do something wrong?
>
> Same with C-u R.
>
>
>>>> and the current tags filtering should apply to the clock table in the
>>>> agenda.
>>>>
>>>> Please test this and report back.
>>> Only minor thing: while the logged lines are correctly shown or made
>>> invisible in the grid time, you need to refresh the table with "g" for it
>>> to display the correct values.
>>>
>>> Until that, what's above is not in sync' with what's in the table. Isn't
>>> there a way to make this refresh happen automatically?
>> That would be possible. However, the whole idea of filtering is to be *very*
>> fast, it works by hiding lines that are already in the buffer. Doing a
>> refresh for each change in filter would be time consuming. So I'd say having
>> to refresh by hand if the clock is showing filtered stuff is the smaller
>> evil.
>
> I would privilege coherency of sums above small delay in table appearance. You
> know, when we look at tables for chasing time, we really need trustable
> figures.
>
> In fact, I don't really understand your argument: if I want quick reports, I
> would just choose for the unfiltered view. If I need detailed sums of clocked
> times, I would go for the "filtrable" view (by C-u R) and would accept a
> little delay.
>
> If you really don't share this vision, could you at least make this
> customizable? TIA.
>
>
>>>>> : | File | L | Headline | Time | |
>>>>> : |------------------+---+----------------------+---------+------|
>>>>> : | | | *Total time* | *10:15* | |
>>>>> : |------------------+---+----------------------+---------+------|
>>>>> : | Clock-Report.org | | *File time* | *10:15* | |
>>>>> : | Clock-Report.org | 1 | Work | 8:09 | |
>>>>> : | Clock-Report.org | 2 | Client A | | 3:23 |
>>>>> : | Clock-Report.org | 2 | Client B | | 4:46 |
>>>>> : | Clock-Report.org | 1 | Personal | 2:06 | |
>>>>> : | Clock-Report.org | 2 | DONE Lunch with Mary | | 2:06 |
>>> Nice new layout. Much clearer for the levels...
>> Yes, I think so to. Try :compact t, that is also nice, I think.
>
> I'll have a look -- when reports will come back to life.
>
>
>>> | File | Headline | Time | |
>>> |------------------+--------------------------+---------+------|
>>> | | ALL *Total time* | *10:15* | |
>>> |------------------+--------------------------+---------+------|
>>> | Clock-Report.org | *File time* | *10:15* | |
>>> | | Work | 8:09 | |
>>> | | \__ Client A | | 3:23 |
>>> | | \__ Client B | | 4:46 |
>>> | | Personal | 2:06 | |
>>> | | \__ DONE Lunch with Mary | | 2:06 |
>
> A couple of days ago, when it still worked, I've just seen something really
> painful: all the Org buffers were referenced in that table, even those which
> should not participate -- because I did not clock any time in them (for that
> or those days).
>
> Plus, having many Org files, in fact, I did not see anymore the lines with the
> real time, as there were many lines with 0:00 time before them...
>
> Best regards,
> Seb
>
next prev parent reply other threads:[~2010-11-19 18:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-27 7:40 Clock report (R from the agenda) Sébastien Vauban
2010-10-27 16:29 ` Bernt Hansen
2010-11-02 8:43 ` Carsten Dominik
2010-11-04 15:39 ` Sébastien Vauban
2010-11-06 19:58 ` Carsten Dominik
2010-11-19 14:04 ` Sébastien Vauban
2010-11-19 18:38 ` Erik Iverson [this message]
2010-11-20 11:29 ` Carsten Dominik
2010-11-22 16:29 ` Erik Iverson
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CE6C442.3030201@ccbr.umn.edu \
--to=eriki@ccbr.umn.edu \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).