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:
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
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
> 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
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,