> On Jan 4, 2020, at 14:20, Kisaragi Hiu <m...@kisaragi-hiu.com> wrote:
>
> It didn't work for me because I gave it "10m" which actually means 10 months,
> I've realized.
>
> Still, Durations as defined by org-duration.el should be described in the
> manual like how Timestamps are.
This does look like a potential contribution to the package.
Jean-Christophe Helary
>
> 2020年1月4日 11:55 差出し人: k...@kyleam.com:
>
>> Kisaragi Hiu <m...@kisaragi-hiu.com> writes:
>>
>>> Currently, the Info node about effort estimates does not mention what
>>> format should it be written in. This causes confusion, as a user might
>>> assume that it's the same format as schedulers (10m, 6h, etc.) like I
>>> did.
>>>
>>> Simply mentioning "Effort estimates need to have the format H:MM"
>>>
>>
>> I don't personally use effort estimates, but quickly poking around I see
>> some indication that estimates should work fine with things like 10min
>> rather than 0:10. In particular org-set-effort has a bit that looks
>> like this:
>>
>> (org-refresh-property '((effort . identity)
>> (effort-minutes . org-duration-to-minutes))
>> value)
>>
>> The presence of org-duration-to-minutes hints to some sort of
>> normalization:
>>
>> (org-duration-to-minutes "10min") ; => 10.0
>> (org-duration-to-minutes "0:10") ; => 10.0
>>
>> And it looks like org-agenda-compare-effort uses the effort-minutes text
>> property. That's presumably why, when I view the entries below in the
>> agenda, org-agenda-filter-by-effort (bound to "_") treats them the same:
>>
>> * TODO a
>> :PROPERTIES:
>> :Effort: 10min
>> :END:
>>
>> * TODO b
>> :PROPERTIES:
>> :Effort: 0:10
>> :END:
>>
>> But that's just one use of effort values, and it sounds like you've hit
>> into cases where the 10min form didn't work as expected. Could you
>> provide more details?
>>
>>> (copied from the docstring or org-effort-property, the only*
>>> description of the format I could find) in the Info node would be
>>> enough.
>>>
>>
>> Given the above, it seems like org-effort-property's docstring is at
>> least somewhat inaccurate.
>>
>
>
Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune