From: andrea@fedeli.eu
To: yantar92@posteo.net
Cc: emacs-orgmode@gnu.org
Subject: Re: [BUG] Error in data input and output format for org-columns--summary-estimate
Date: Fri, 14 Jul 2023 13:39:42 +0200 [thread overview]
Message-ID: <RXSB26$31CC50B784CF89D0AFACC55F32997B41@fedeli.eu> (raw)
In-Reply-To: <87mszyj27n.fsf@localhost>
[-- Attachment #1: Type: text/plain, Size: 4122 bytes --]
Howdy!
Da "Ihor Radchenko" yantar92@posteo.net
A andrea@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 ]
"andrea@fedeli.eu" <andrea@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>
[-- Attachment #2: Type: text/html, Size: 5641 bytes --]
next prev parent reply other threads:[~2023-07-14 11:45 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-09 12:46 [BUG] Error in data input and output format for org-columns--summary-estimate andrea
2023-07-09 14:17 ` Ihor Radchenko
2023-07-09 14:33 ` andrea
2023-07-10 8:57 ` Ihor Radchenko
[not found] ` <RXR2XJ$F3602788F3665C159BAF986799B1995C@fedeli.eu>
2023-07-14 9:02 ` Ihor Radchenko
2023-07-14 11:39 ` andrea [this message]
2023-07-18 9:10 ` Ihor Radchenko
2023-08-15 15:53 ` andrea
2023-08-16 10:15 ` Ihor Radchenko
2023-08-18 6:20 ` andrea
2023-08-18 9:29 ` Ihor Radchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='RXSB26$31CC50B784CF89D0AFACC55F32997B41@fedeli.eu' \
--to=andrea@fedeli.eu \
--cc=emacs-orgmode@gnu.org \
--cc=yantar92@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).