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

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

[Axel Kielhorn]

Hello!

Since the est+ format is working again for regular column view, I tried updating my files and ran into a new problem:

When I’m on the #+BEGIN: columnview line and type C-C C-C the dynamic view is not updated.

I get:
org-duration-to-minutes: Invalid duration format: "2.0-5.5“
and
Columnview is entered for the referenced data.

Same happens when I call org-update-dblock.

Adding
:format "%40ITEM(Task) %12Effort(Estimate){estc+}“
to the #+BEGIN: columnview line doesn’t help.

First seen on
Org mode version 9.4.5 (release_9.4.5-530-g981f25 @ /Users/axel/src/Emacs/org-mode/lisp/)
still in
Org mode version 9.4.5 (release_9.4.5-578-g1d99f5 @ /Users/axel/src/Emacs/org-mode/lisp/)


#+TITLE: ECM
#+AUTHOR: Axel Kielhorn

* Estimate
:PROPERTIES:
:COLUMNS: %40ITEM(Task) %12Effort(Estimate){est+}
:ID: Arbeitszeiten
:END:

** Little Thing
  :PROPERTIES:
  :Effort:   2.0-5.5
  :END:
** Big Mess
  :PROPERTIES:
  :Effort:   8.0-30.0
  :END:


* The Reconing

#+BEGIN: columnview :hlines 1 :id "Arbeitszeiten"

#+END:

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

[Axel Kielhorn]

In columnview mode the estimate is calculated[1] but the dynamic block doesn’t get updated.

I did some bisecting and the last version where both column view and dynamic block were working is:

Merge branch 'maint'	1aeb958e5	Marco Wahl <marcowahlsoft@gmail.com>	12.02.2017, 09:19

In

Use Org duration library	7e8cf5f4c	Nicolas Goaziou <mail@nicolasgoaziou.fr>	13.02.2017, 14:41

neither column view nor dynamic block is working.



For the column view this was fixed in:

Merge branch 'maint'	2f200f50d	Bastien <bzg@gnu.org>	03.05.2021, 15:59

(But I don’t understand how this fixes the problem.)

For the dynamic block the updating does not work.
Since this was broken for 4 years I think no-one uses it.

[1] The „est+“  function only adds integers and doesn’t work with times like 0:15.
This is to be expected since it is a „+“ function, otherwise it would be „est:“.
One could argue that an „est:“ function would be more appropriate, 
but since no-one seems to use this feature, I’m not the one to argue that.

Maybe a note in the documentation would be sufficient:

Note that this is a =+= function that adds numbers, not a =:= which handles times.

Do you want a patch for that?

Greetings
Axel

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

[Nicolas Goaziou]

Hello,

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

> In columnview mode the estimate is calculated[1] but the dynamic block doesn’t get updated.
>
> I did some bisecting and the last version where both column view and dynamic block were working is:
>
> Merge branch 'maint'	1aeb958e5	Marco Wahl <marcowahlsoft@gmail.com>	12.02.2017, 09:19
>
> In
>
> Use Org duration library	7e8cf5f4c	Nicolas Goaziou <mail@nicolasgoaziou.fr>	13.02.2017, 14:41
>
> neither column view nor dynamic block is working.
>
>
>
> For the column view this was fixed in:
>
> Merge branch 'maint'	2f200f50d	Bastien <bzg@gnu.org>	03.05.2021, 15:59
>
> (But I don’t understand how this fixes the problem.)
>
> For the dynamic block the updating does not work.
> Since this was broken for 4 years I think no-one uses it.
>
> [1] The „est+“  function only adds integers and doesn’t work with times like 0:15.
> This is to be expected since it is a „+“ function, otherwise it would be „est:“.
> One could argue that an „est:“ function would be more appropriate, 
> but since no-one seems to use this feature, I’m not the one to argue that.
>
> Maybe a note in the documentation would be sufficient:
>
> Note that this is a =+= function that adds numbers, not a =:= which handles times.
>
> Do you want a patch for that?

I think the issue is different. 

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.

Maybe Effort property should simply accept a duration or a duration
range.

Regards,
-- 
Nicolas Goaziou

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

[Axel Kielhorn]

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

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.

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

Some functions only expect 1 value for the effort, which is the correct value?
What happens when I : add a range?

The dynamic block code juggles with conversion to minutes, which is wrong when a range is involved.

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

> 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?

1.0 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???

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.

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

The more I think about that, the more questions I have.

To be honest, I’m not even sure I will use the est+ function in real life.
(I discovered it when preparing some training material and thought that was interesting.)
I’ll probably just : add the hours and add 10% safety margin on top.
But since the feature is advertised it would be great if it works.

Would I be sorry if you deprecate this feature? Probably not.
Will anyone notice? Probably not, it has been broken for 4 years.

Greetings
Axel

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,