Howdy! Da "Ihor Radchenko" yanta...@posteo.net A and...@fedeli.eu Cc emacs-orgmode@gnu.org Data Fri, 14 Jul 2023 09:02:04 +0000 Oggetto Re: [BUG] Error in data input and output format for org-columns--summary-estimate [ Adding Org ML back to CC. Please use "reply all" to reply on the mailing list ]
"and...@fedeli.eu" <and...@fedeli.eu> writes: > I do apologize, I noticed only now the patch content: the output > format of duration-from-minutes Is controlled by the > org-duration-format variable, so if the user wants results in > months (s)he can easily get It that way. `org-duration-format' is controlling many other aspects of formatting. Customizing, for example, agenda should probably not affect column views. AF: I think we need to univoquely clarify which unit is to be used in estimation. As shown below org documentation suggests time it to be used for that, from there it cames the idea to turn times into minutes for computation reason; maybe we may introduce a new format variable for estimation results reporting. I thought I might use org-duration-from-minutes for that, as it came very handy. > About possibile abuses, org documentation, to date, clearly tells > org estimate utilizes times. May you please elaborate? AF: Sure! Clause 8.5 of current (2023.Jul.14) org documentation, https://orgmode.org/manual/Effort-Estimates.html, refers to effort estimates giving examples that are all appearing to fall in time domain. In particular it refers to org-duration.el for format information. That, IMO, establish that efforts have to refer to org-duration units. Now, the *default* values of org-duration are *clearly* time measures. From there my assumption about the fact that I may use the org-duration-to-minutes and org-duration-from-minutes adapters. Clearly, you /may/ decide to completely redefine the org-duration basis, but that would mean to coherently propagate the information change everywhere somebody used org-duration-units which, even though LisP is a very flexible language, is NOT what I'd expect org-duration utilizer always foresaw to have to be flexible in terms of. > Similarly, I'd not spend too much code to check the format; i > understand the intent to preserve backward compatibility, bit if > that format adaptation mistake slipped forward to these days I > doubt that nice feature was used much so far... Yes, but it is easy to have a fallback, so why not. Because this way you persist in allowing a mistaken usage of that function. A number is a number but a duration is NOT just a number, and having something like (just for example) 10kg-0.5ton be taken as 10-0.5 is in my opinion NOT helpful to any user. The pcase matches either value pairs or single values, and org-duration-to-minutes can be charged to decide on what to do if values did not match the proper format (with the default assumption, I'd say, that simple integers are minutes). In facts org-duration-to-minutes already has a cond classical closing (t ...) branch to deal with that case. I'd leave the rest as I suggested; maybe, if you --as maintainer hence exposed to the global amount of supports request and use cases-- see that as convenient, with a different output format adapter than the one I picked (org-duration-from-minutes without an extra format specification actual argument); already allowing a custom format adapter would introduce an extra flexibility knob BUT consider that org-duration-to-minutes does NOT do the same (it implicitly utilizes the org-duration-format content, and has hardcoded assumption on quantities being representing times, so there too you'd need to change something, if it was not just a matter of definining a different alternative to display result times). Cheers! Andrea. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
