From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id sEKXJduf22QU3QAASxT56A (envelope-from ) for ; Tue, 15 Aug 2023 17:55:07 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id qPyUJduf22RDFQEAauVa8A (envelope-from ) for ; Tue, 15 Aug 2023 17:55:07 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 0ACC839D6A for ; Tue, 15 Aug 2023 17:55:07 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=aruba.it header.s=a1 header.b=LPEWoAqn; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1692114907; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=yRyd3IkoimWdxxKYevKDkpmg8TwXWfi5OIDxplnjaMw=; b=Ph3RwsYutj1kMsVDaySvFjOdMDf5nUTopzoWiqux8XNiWuMwcrZznjy4yrH6rQ66fh+6JQ SNVYt5maznSjWJJpI4mkRoI+25aJwwz2tWi8QI4LXzaUg7yn5unB3e65hNvEPCognYJ5Xu n0bvfQqQeGffwgBZ3RlzvdTyp3YkXdVDf9whje98MlTuMc81Ok0Kj75ct44kZIkkZ7VxFn xudiBtQCRLCC4VlXT+79kXHtvfJPlNkcDz8DeeoNjB3sc5C77DAGCQTBxl4t0a0oyJmhMX oqtAkhjazkcfg4N9dm9KRGOteBLdztwUbuNTXVS8Vnp0tadp30vGm74vG8BsPg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=aruba.it header.s=a1 header.b=LPEWoAqn; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1692114907; a=rsa-sha256; cv=none; b=NOsDsFwRFrtxcSa41fXX2awVYVwtzhKcS8cYLnN2geCNUP0+FWb6zrUYFwL883qaMc7zjt HVbpGkxwedfIQ4CWmo6rvyDRNXY4mJSs/WHTEbmyv2ROv2lxs6EnLUx2tv1PAQPvwE11pd cVF6poDim6UR/OM+uZUjD6gLqYbZ4EpaR6pmL2MG4sRAqE5b1fsyR8FlTpvCWwJeR0Rpm8 9PXwV5dT71D7rAokxA2HLaIY0meVxquZvXvaIEEF4vA78JXeigRw0DQEFvYLMieQQIlzAT phn2qU6KkoengnZ6vkyx1mGBOpU/bFUz/40HieudL05YNk3WeQZHPrlsdkcdqg== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qVwMt-0000O3-Ay; Tue, 15 Aug 2023 11:54:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qVwMr-0000NU-Qj for emacs-orgmode@gnu.org; Tue, 15 Aug 2023 11:54:02 -0400 Received: from smtpdh16-w.aruba.it ([62.149.155.109]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qVwMn-0002yx-99 for emacs-orgmode@gnu.org; Tue, 15 Aug 2023 11:54:01 -0400 Received: from fedeli.eu ([10.10.10.162]) by Aruba Outgoing Smtp with ESMTPA id VwMgqk0OQkcRjVwMgqpCjO; Tue, 15 Aug 2023 17:53:51 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aruba.it; s=a1; t=1692114831; bh=1aNkCemVDR9ucmhUrbpS6HAO8vO33CSJDbM5DvpfhBU=; h=Date:Subject:MIME-Version:Content-Type:From:To; b=LPEWoAqnDWPEBf8NFePCzOjnoMuwIwFyUk9nq++Lwkq/G4xMPBKijIZHbMnfuM0W9 YiZC6Lj/34mVSlPrcad1QyljCibQk0R2vtvxJPXPgItl23pYrJ5l3druPvak+CZ7ka RHq9QkSC0fQ/eQiu8RxNkpYz3R2CXbovOQL6aLZHbyGFQ4Nal8zLZo4zjKNTLUEpPe JF5quBLjFxINXCqb8rB4y3Zv+JnZ5t7vIz99PwDC7FJFk+1p9v4S3DubK+fjRu+K8r yHN/j/fxnSk6L8O3D/YkDT1KSwRf1PwoJ6XVSQMYX6/7Twb67Tdebn9H6Cb/DGHcM2 dyMnZQLtuDbiQ== Date: Tue, 15 Aug 2023 17:53:50 +0200 Message-Id: In-Reply-To: <871qh5wpo6.fsf@localhost> References: =?iso-8859-1?q?=3CRXJ4U3=24C6D44098F78E9824538618D9BEAECEDA=40fedeli?= =?iso-8859-1?q?=2Eeu=3E_=3C87y1jp6ueg=2Efsf=40localhost=3E_=3CRXJ9RW?= =?iso-8859-1?q?=24A3C3D79D027C4334488CC937B6873333=40fedeli=2Eeu=3E_?= =?iso-8859-1?q?=3C87ilas6t4v=2Efsf=40localhost=3E_=3CRXR2XJ=24F360278?= =?iso-8859-1?q?8F3665C159BAF986799B1995C=40fedeli=2Eeu=3E_=3C87mszyj2?= =?iso-8859-1?q?7n=2Efsf=40localhost=3E_=3CRXSB26=2431CC50B784CF89D0AF?= =?iso-8859-1?q?ACC55F32997B41=40fedeli=2Eeu=3E_=3C871qh5wpo6=2Efsf=40?= =?iso-8859-1?q?localhost=3E?= Subject: =?utf-8?b?UmU6IFtCVUddIEVycm9yIGluIGRhdGEgaW5wdXQgYW5kIG91dHB1dCBm?= =?utf-8?b?b3JtYXQgZm9yIG9yZy1jb2x1bW5zLS1zdW1tYXJ5LWVzdGltYXRl?= MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: multipart/alternative; boundary="_=__=_XaM3_.1692114830.2A.884246.42.4408.52.42.007.1608846446" From: andrea@fedeli.eu To: yantar92@posteo.net Cc: emacs-orgmode@gnu.org X-XaM3-API-Version: 4.2.88 X-TipoRicevuta: completa X-type: 0 X-SenderIP: 188.12.198.247 X-CMAE-Envelope: MS4xfEb6KX/nAgLNQT71JibjDg2kklOLMks7i1WTUkujit37ESHpSCnkEmaNLTbZ9aydOMrFSn1uswr+R5j54TXnMSTuHBSPIpw0RowOr3pXLXXfPPeRWn1O f+9R8+4geb0NoSFQ6FGXC0C2ojPaj51EasMhSxa7TlaxBN31vpxveqIizS6SyDW/IeEOEvVZ5fpdqVDH/boCa4ZXTKwb77O6B9Q= Received-SPF: pass client-ip=62.149.155.109; envelope-from=andrea@fedeli.eu; helo=smtpdh16-w.aruba.it X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: andrea@fedeli.eu Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Queue-Id: 0ACC839D6A X-Migadu-Scanner: mx1.migadu.com X-Spam-Score: -7.36 X-Migadu-Spam-Score: -7.36 X-TUID: 5fmTaDKRRp2f --_=__=_XaM3_.1692114830.2A.884246.42.4408.52.42.007.1608846446 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A Howdy!=0A 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 t= o deal with ranges: org-clock-get-clock-string and=0A 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 (qu= ite handy, I have to say, as you're immediately warned you've running bey= ond estimations. For those two functions, I have introduced a similar cha= nge 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 d= ebug-on-entry feature :))=0A Two considerations here:=0A 1. I underst= and the fact that est+ doesn't have to necessarily be associated with eff= ort, but it is quite clear from the docs which is the intent with which i= t was introduced: the only provided example is on times, and there we hav= e to consider that time is expressed in durations.=0A What I mean is th= at it does NOT make much sense to me to tell users the effort is to be wr= itten 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 el= se some other duration unit is used..=0A 2. Said differently, whether i= t was practically used also somewhere else, and not for time estimation, = I can say nothing about; it is already quite hard to find it in doc, to d= ate, and there the only example given is about time.=0A As without my = changes the effort fork would not work properly in org-clock functions, i= f we really think estimation ranges shall be used also somewhere else I t= hink we need to consider a possible generalization of what a duration is.= In facts if we want to utilize it for other kind of measuring units (wei= ght, money, etc.), it might make sense to pair it with a proper translati= on table like the one of duration that allows to convert days, hours, wee= ks, etc. into minutes, back and forth; this way we might allow both a pro= per type check according to the utilized measure unit, and would be able = to avoid having to misleadlingly allow to sum tons to kg, for instance. (= Recall: the ending letter today is just discarded hence 1kg-1ton is today= taken as 1-1).=0A Cheers,=0A Andrea.=0A=0A Da "Ihor Radchenko" y= antar92@posteo.net=0A A andrea@fedeli.eu=0A Cc emacs-orgmode@gnu.org=0A= Data Tue, 18 Jul 2023 09:10:33 +0000=0A Oggetto Re: [BUG] Error in d= ata input and output format for org-columns--summary-estimate=0A andrea= @fedeli.eu writes:=0A=0A >> About possibile abuses, org documentation, = to date, clearly tells=0A >> org estimate utilizes times.=0A >=0A >= > May you please elaborate?=0A=0A > AF: Sure! Clause 8.5 of current=0A = > (2023.Jul.14) org documentation,=0A > https://orgmode.org/manual/Ef= fort-Estimates.html, refers to effort=0A > estimates giving examples th= at are all appearing to fall in time=0A > domain.=0A=0A I see what yo= u mean.=0A However, est+ column summary does not have to be applied to = EFFORT=0A columns.=0A=0A One can, for example, use %SCORE{est+} colum= n specification to summarize=0A values stored in SCORE property. Org ha= s no right to demand SCORE to be=0A in time units and only time units.=0A= =0A > > Similarly, I'd not spend too much code to check the format; i=0A= > > understand the intent to preserve backward compatibility, bit if=0A= > > that format adaptation mistake slipped forward to these days I=0A = > > doubt that nice feature was used much so far...=0A >=0A > Yes, = but it is easy to have a fallback, so why not.=0A=0A > Because this way= you persist in allowing a mistaken usage of that=0A > function. A numb= er is a number but a duration is NOT just a number,=0A > and having som= ething like (just for example) 10kg-0.5ton be taken=0A > as 10-0.5 is i= n my opinion NOT helpful to any user.=0A=0A We may provide a linter (fo= r M-x org-lint) that will ensure EFFORT=0A estimates to be in understan= dable format.=0A=0A --=0A Ihor Radchenko // yantar92,=0A Org mode c= ontributor,=0A Learn more about Org mode at .=0A = Support Org development at ,=0A or su= pport my work at =0A --_=__=_XaM3_.1692114830.2A.884246.42.4408.52.42.007.1608846446 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Howdy!

I'm back to a previous element partially di= scussed as I found other org places where the duration had to be adapted = to be able to deal with ranges: org-cloc= k-get-clock-string and=C2=A0
org-clock-notify-once-if-expired, both in og-clock.el; both get into action if you have a tas= k 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 spl= it-string to org-duration to minutes. Thanks, Sant Ignucius, for the debu= g-on-entry feature :))

Two considerations here:

1. = I understand the fact that est+ doesn't have to necessarily be ass= ociated with effort, but it is quite clear from the docs which is the int= ent 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 use= d..

2. Said differently, whether it was practically use= d also somewhere else, and not for time estimation, I can say nothing abo= ut; it is already quite hard to find it in doc, to date, and there=C2=A0 = the only example given is about time.

As without my cha= nges the effort fork would not work properly in org-clock functions, if w= e really think estimation ranges shall be used also somewhere else I thin= k we need to consider a possible generalization of what a duration is. In= facts if we want to utilize it for other kind of measuring units (weight= , money, etc.), it might make sense to pair it with a proper translation = table like the one of=C2=A0duration=C2=A0that allows to convert da= ys, hours, weeks, etc. into minutes, back and forth; this way we might al= low both a proper type check according to the utilized measure unit, and = would be able to avoid having to misleadlingly allow to sum tons to kg, f= or instance. (Recall: the ending letter today is just discarded hence 1kg= -1ton is today taken as 1-1).

Cheers,

=C2=A0 Andrea= .
=C2=A0

Da<= span style=3D"font-family:Arial; font-size:12px; color:#5F5F5F; padding-l= eft:5px;"> "Ihor Radchenko" yantar92@posteo.net
=0A=
A<= /span> andrea@fedeli.eu
=0A
Cc emac= s-orgmode@gnu.org
=0A
Data Tue, 18 Jul 2023 09= :10:33 +0000
=0A
Oggetto Re: [BUG] Error in da= ta input and output format for org-columns--summary-estimate
= =0A
=0A
andrea@fedeli.eu writes:
=C2=A0
>= > About possibile abuses, org documentation, to date, clearly tells
>> org estimate utilizes times.
>=C2=A0
<= div>>> May you please elaborate?
=C2=A0
> = AF: Sure! Clause 8.5 of current
> (2023.Jul.14) org doc= umentation,
> https://orgmode.org/manual/Effort-Estimates= .html, refers to effort
> estimates giving examples that = are all appearing to fall in time
> domain.
=C2= =A0
I see what you mean.
However, est+ column summary= does not have to be applied to EFFORT
columns.
=C2=A0=
One can, for example, use %SCORE{est+} column specification to= summarize
values stored in SCORE property. Org has no right to= demand SCORE to be
in time units and only time units.
=C2=A0
> > Similarly, I'd not spend too much code to= check the format; i
> > understand the intent to pres= erve backward compatibility, bit if
> > that format ad= aptation mistake slipped forward to these days I
> > d= oubt that nice feature was used much so far...
>=C2=A0
=
> Yes, but it is easy to have a fallback, so why not.
=C2=A0
> Because this way you persist in allowing a mis= taken usage of that
> function. A number is a number but = a duration is NOT just a number,
> and having something l= ike (just for example) 10kg-0.5ton be taken
> as 10-0.5 i= s in my opinion NOT helpful to any user.
=C2=A0
We ma= y provide a linter (for M-x org-lint) that will ensure EFFORT
e= stimates to be in understandable format.
=C2=A0
--
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>
<= /div>
--_=__=_XaM3_.1692114830.2A.884246.42.4408.52.42.007.1608846446--