IR > May you share your changes?
Sure!
Here they are: In these slices I take the upper part of the fork (where in
case, assuming a small-big usage convention ;)) as that is the value that
surely testify the effort estimation overrun. Being so, at the time of this
writing I just realized the use of pcase is likely replaceable by a simpler
(car (last (mapcar...))) call :).
Cheers,
Andrea
Job: diff -bwi org-clock.el{.old,}
720c720,723
< (let* ((effort-in-minutes (org-duration-to-minutes org-clock-effort))
---
> (let* ((effort-in-minutes
> (pcase (mapcar #'org-duration-to-minutes (split-string
org-clock-effort "-"))
> (`(,_ ,value) value)
> (`(,value) value)))
828c831,833
< (let ((effort-in-minutes (org-duration-to-minutes org-clock-effort))
---
> (let ((effort-in-minutes (pcase (mapcar #'org-duration-to-minutes
(split-string org-clock-effort "-"))
> (`(,_ ,value) value)
> (`(,value) value)))
Da [email protected]
A [email protected]
Cc [email protected]
Data Wed, 16 Aug 2023 10:15:13 +0000
Oggetto Re: [BUG] Error in data input and output format for
org-columns--summary-estimate
[email protected] writes:
> Howdy!
> I'm back to a previous element partially discussed as I found other org
places where the duration had to be adapted to be able to deal with ranges:
org-clock-get-clock-string and
> org-clock-notify-once-if-expired, both in og-clock.el; both get into
action if you have a task you estimated and for which you're now tracking
development time (quite handy, I have to say, as you're immediately warned
you've running beyond estimations. For those two functions, I have introduced a
similar change to the one I did originally to go from the basic string-to
number on split-string to org-duration to minutes. Thanks, Sant Ignucius, for
the debug-on-entry feature :))
May you share your changes? I am not sure if I fully understand what and
why you did without seeing the diff.
> Two considerations here:
> 1. I understand the fact that est+ doesn't have to necessarily be
associated with effort, but it is quite clear from the docs which is the intent
with which it was introduced: the only provided example is on times, and there
we have to consider that time is expressed in durations.
> What I mean is that it does NOT make much sense to me to tell users the
effort is to be written as 3d if given as a single value, and it has to be
rewritten as 3-5 if we want to say "in a fork of 3 to 5 days", especially if
somewhere else some other duration unit is used..
It should not. The reason `org-columns--summary-estimate' uses
split-string is because it may have to work with recursively calculated
estimates from subtrees. EFFORT property itself does not officially
support ranges.
--
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>
