Re: [O] [PATCH] `org-clock--oldest-date` performance

[Jack Henahan]

I wasn't altogether certain that it could never be nil, and my eyes seem
to have skipped over the expression you called out so I missed that case
in my testing. I have reworked the patch as you suggest. Now the
behavior should be entirely unchanged except in the `untilnow' case
where we use the new date, no extra nils.

Revised patch attached.

Nicolas Goaziou <address@hidden> writes:

> Hello,
>
> Jack Henahan <address@hidden> writes:
>
>> Functionally, this means that today `org-clock-special-range` produces a
>> range from the current time until the current time if `start` ends up
>> nil for whatever reason
>
> That's not true. Currently, `org-clock-special-range' never returns
> a nil start time. This is where I don't understand your patch:
>
>> -                (`untilnow org-clock--oldest-date)
>> +                (`untilnow nil)
>>                  (_ (encode-time 0 m h d month y))))
>>         (end (pcase key
>>                (`interactive (org-read-date nil t nil "Range end? "))
>> @@ -2283,8 +2251,12 @@ have priority."
>>            (`interactive "(Range interactively set)")
>>            (`untilnow "now"))))
>>        (if (not as-strings) (list start end text)
>                                     ^^^^^
>                               this can now be nil
>> -    (let ((f (cdr org-time-stamp-formats)))
>> -      (list (format-time-string f start)
>> +    (let ((f (cdr org-time-stamp-formats))
>> +              (safe-start
>> +           (if (not start)
>> +               (encode-time 0 0 0 0 0 -50000)
>> +             start)))
>> +      (list (format-time-string f safe-start)
>>              (format-time-string f end)
>>              text))))))
>
> Why not replacing `org-clock--oldest-date' with (encode-time
> 0 0 0 0 0 -50000) in the let binding above?
>
> Regards,

0001-org-clock.el-Improve-untilnow-range-behavior-and.patch
Description: Text Data