Re: Updating column view dynamic block does not work with {est+}

[Nicolas Goaziou]

Axel Kielhorn <org-mode@axelkielhorn.de> writes:

>> Am 20.05.2021 um 19:58 schrieb Nicolas Goaziou <mail@nicolasgoaziou.fr>:
>> 
>> Org Duration is strict about what it is fed with (which is good). Effort
>> property expects a duration as value. But "3-8" is not a valid duration.
>> However, "3" is a valid duration; it means 3 minutes.
>
> The problem is that effort can either be a duration and in that case the 
> strict duration library ist fine.
> Or it can be a range (of days).

No, it means minutes. However, units do not matter in "est+". You can
interpret the result in days if it matters.

> 3:30 is fine when : is used to add the times
> 3.0 - 4.0 is a range estimate when est+ is used
> 3:00 - 4:00 is only correct by chance, 3:30 - 4:30 will lead to the
> same result since est+ does not handle durations.

This is what I'm suggesting, isn't it?

> Splitting it into 2 properties (effort and effort_range) is even worse
> since it will be inconsistent after a few edits.

This is _not_ what I'm suggesting.

> It gets even more interesting when on task has 3-4 (implicit) days, while 
> another has 8:00 (implicit) hours.
> (Are 8 h one work day, or are 24 h one calendar day?)

Org Duration library is able to distinguish canonical from user-provided
units (see last argument in `org-duration-to-minutes). Actually, Org
Colview makes this distinction by calling "canonical" duration an "age"
(see "@min" and other operators).

There could be est+ and est-age+ (or anything else, really).

>> Maybe Effort property should simply accept a duration or a duration
>> range.
>
> That’s what I first thought it would do, since a duration is a time (8:00 for 
> 8h).
> The question is how to resolve ambiguity?

I don't see any ambiguity. est+ can be changed to accept 2d-3d.

> 1.0 is one day

No, it's one minute. 1.0d is one day.

> 1:00 is one hour
> 1 is one minute, really? yes, that is the default for the duration
> library. But it used to mean one day???

A long time ago, yes, but that was inconsistent.

> Maybe a new est: function to work with durations and the old est+ function to 
> work with numbers 
> (which could mean days, but it could mean ms as well)? And a warning about 
> inconsistent units.

I don't think this is needed. The current est+ is not working anyway.

> What happens when I use a range in a clock table?

Who knows? :)

> But since the feature is advertised it would be great if it works.

There's no reason it cannot work. It just needs some love.

Regards,