[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] lisp/org-clock.el (org-clock-sum): Rewrite regex using rx
From: |
Morgan Smith |
Subject: |
Re: [PATCH] lisp/org-clock.el (org-clock-sum): Rewrite regex using rx |
Date: |
Wed, 19 Jun 2024 14:24:08 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Ihor Radchenko <yantar92@posteo.net> writes:
>> Ideally the fix in that commit should be ported to the org-element API.
>> Notably, the malformed clock from the email thread from that commit is
>> parsed a little strangely by org-element. I'm not sure what effect this
>> has on my rewrite patch but regardless, we should probably fix this.
>> Notice how ":day-end" and ":minute-end" are set but not ":hour-start" or
>> ":minute-start".
>
> That's expected.
> We have the following _syntax_ description for clock lines:
>
> https://orgmode.org/worg/org-syntax.html#Clocks...
> clock: INACTIVE-TIMESTAMP-RANGE DURATION
>
> And [2012-01-01 sun. 00rr:01] is a perfectly valid timestamp without
> time part. Org does allow arbitrary additional text in the timestamps.
> (it is by design, to allow future extensions of the syntax, like the
> planned timezone support)
My specific issue is that the ":*-end" stuff can be set when the
"*-start" stuff is not.
Running the following snippet on the following file results in this:
======= snippet
(org-element-cache-map
(lambda (clock)
"Calculate end-time - start-time"
(let ((timestamp (org-element-property :value clock)))
(- (float-time (org-timestamp-to-time timestamp t))
(float-time (org-timestamp-to-time timestamp)))))
:granularity 'element
:restrict-elements 'clock)
========
======== file
* Test
CLOCK: [2023-11-15 Wed 15:26]--[2023-11-15 Wed 16:12] => 0:46
calculated time: 2760.0
CLOCK: [2023-11-15 Wed 15rr:26]--[2023-11-15 Wed 16:12] => 0:46
calculated time: 58320.0
CLOCK: [2023-11-15 Wed 15:26]--[2023-11-15 Wed 16rr:12] => 0:46
calculated time: 0.0
CLOCK: [2023-11-15 Wed 15rr:26]--[2023-11-15 Wed 16rr:12] => 0:46
calculated time: 0.0
=======
======= results
(2760.0 58320.0 0.0 0.0)
======
What this shows is that an invalid end will cause the entry to be
ignored, but an invalid start will not.
We can totally claim that this is a feature, not a bug, if you would
like. As this essentially treats
"CLOCK: [2023-11-15 Wed 15rr:26]--[2023-11-15 Wed 16:12] => 0:46"
as
"CLOCK: [2023-11-15 Wed]--[2023-11-15 Wed 16:12] => 16:12"
If this is a feature then my previous patch is actually ready to merge.