emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Why is ":CLOCK => hh:mm" allowed as a clock entry?
@ 2018-10-18  7:33 Marcin Borkowski
  2018-10-20  8:26 ` Nicolas Goaziou
  0 siblings, 1 reply; 3+ messages in thread
From: Marcin Borkowski @ 2018-10-18  7:33 UTC (permalink / raw)
  To: Org-Mode mailing list

Hi all,

I am studying the `org-clock-sum' function (I need to parse an Org file
and extract clocking data), and I noticed that ":CLOCK => hh:mm" is
allowed as a clock entry.  The Org syntax at
https://orgmode.org/worg/dev/org-syntax.html#Clock,_Diary_Sexp_and_Planning
confirms this.

What is the rationale behind this?  I want not only to sum the clocks
(org-clock-sum does that, of course), but I want more detailed
information (like how many clocks were that in the given period etc.).
The format with only the duration makes this troublesome, and I'd like
to ignore such entries (I have never seen them in my files, of course).
I'm wondering what scenario could lead to their existence?

BTW, the syntax draft says that there can be any TIMESTAMP object before
the DURATION, but `org-clock-sum' assumes that its timestamps are
inactive.  Isn't that a bug?

TIA,

--
Marcin Borkowski
http://mbork.pl

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Why is ":CLOCK => hh:mm" allowed as a clock entry?
  2018-10-18  7:33 Why is ":CLOCK => hh:mm" allowed as a clock entry? Marcin Borkowski
@ 2018-10-20  8:26 ` Nicolas Goaziou
  2018-10-21 19:50   ` Marcin Borkowski
  0 siblings, 1 reply; 3+ messages in thread
From: Nicolas Goaziou @ 2018-10-20  8:26 UTC (permalink / raw)
  To: Marcin Borkowski; +Cc: Org-Mode mailing list

Hello,

Marcin Borkowski <mbork@mbork.pl> writes:

> I am studying the `org-clock-sum' function (I need to parse an Org file
> and extract clocking data), and I noticed that ":CLOCK => hh:mm" is
> allowed as a clock entry.  The Org syntax at
> https://orgmode.org/worg/dev/org-syntax.html#Clock,_Diary_Sexp_and_Planning
> confirms this.

  CLOCK:

and

  CLOCK: => hh:mm

are simply empty clocks.

> What is the rationale behind this?

Treating them as regular text would complicate parsing unnecessarily,
e.g., to determine when to stop a paragraph. 

There are other cases that can lead to odd clocks:

  CLOCK: INACTIVE-TIMESTAMP => HH:MM

where INACTIVE-TIMESTAMP is not a timestamp range.

> I want not only to sum the clocks (org-clock-sum does that, of
> course), but I want more detailed information (like how many clocks
> were that in the given period etc.). The format with only the duration
> makes this troublesome, and I'd like to ignore such entries (I have
> never seen them in my files, of course). I'm wondering what scenario
> could lead to their existence?

Hand-writing a clock information?

In any case, you can simply ignore them whenever you find them – which
shouldn't happen, right?

We can also add a checker in Org Lint for those problematic cases.

> BTW, the syntax draft says that there can be any TIMESTAMP object before
> the DURATION, but `org-clock-sum' assumes that its timestamps are
> inactive.  Isn't that a bug?

This is an oversight. Clock timestamps must be inactive. I will fix it.

Thank you.

Regards,

-- 
Nicolas Goaziou

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Why is ":CLOCK => hh:mm" allowed as a clock entry?
  2018-10-20  8:26 ` Nicolas Goaziou
@ 2018-10-21 19:50   ` Marcin Borkowski
  0 siblings, 0 replies; 3+ messages in thread
From: Marcin Borkowski @ 2018-10-21 19:50 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: Org-Mode mailing list


On 2018-10-20, at 10:26, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

> Hello,
>
> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> I am studying the `org-clock-sum' function (I need to parse an Org file
>> and extract clocking data), and I noticed that ":CLOCK => hh:mm" is
>> allowed as a clock entry.  The Org syntax at
>> https://orgmode.org/worg/dev/org-syntax.html#Clock,_Diary_Sexp_and_Planning
>> confirms this.
>
>   CLOCK:
>
> and
>
>   CLOCK: => hh:mm
>
> are simply empty clocks.
>
>> What is the rationale behind this?
>
> Treating them as regular text would complicate parsing unnecessarily,
> e.g., to determine when to stop a paragraph. 

OK, I don't fully get it, but I believe you. :-)

> There are other cases that can lead to odd clocks:
>
>   CLOCK: INACTIVE-TIMESTAMP => HH:MM
>
> where INACTIVE-TIMESTAMP is not a timestamp range.
>
>> I want not only to sum the clocks (org-clock-sum does that, of
>> course), but I want more detailed information (like how many clocks
>> were that in the given period etc.). The format with only the duration
>> makes this troublesome, and I'd like to ignore such entries (I have
>> never seen them in my files, of course). I'm wondering what scenario
>> could lead to their existence?
>
> Hand-writing a clock information?
>
> In any case, you can simply ignore them whenever you find them – which
> shouldn't happen, right?

Yes, that's what I thought.

> We can also add a checker in Org Lint for those problematic cases.

Might be a good idea, though definitely very low priority.

>> BTW, the syntax draft says that there can be any TIMESTAMP object before
>> the DURATION, but `org-clock-sum' assumes that its timestamps are
>> inactive.  Isn't that a bug?
>
> This is an oversight. Clock timestamps must be inactive. I will fix it.

Thanks.

Best,

-- 
Marcin Borkowski
http://mbork.pl

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-10-21 19:57 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-18  7:33 Why is ":CLOCK => hh:mm" allowed as a clock entry? Marcin Borkowski
2018-10-20  8:26 ` Nicolas Goaziou
2018-10-21 19:50   ` Marcin Borkowski

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).