From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id GD+1G3c1sWSfSAEASxT56A (envelope-from ) for ; Fri, 14 Jul 2023 13:45:59 +0200 Received: from aspmx1.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id UMGCG3c1sWQ+CwEA9RJhRA (envelope-from ) for ; Fri, 14 Jul 2023 13:45:59 +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 E2BBA4BD82 for ; Fri, 14 Jul 2023 13:45:58 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=aruba.it header.s=a1 header.b=dUrCf+Fr; dmarc=none; 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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1689335159; a=rsa-sha256; cv=none; b=eRkGjbdbVBua2RNw8X8KeMSuBhd1IS8gArFoKZyJARKGBzgefbGJ6gXaef/LD2yDTGNxch 8t/bACFNgbwAfvvvf+D7H9QwkmP7DKntLxH7dFHu8vT2l7rQfDTQ8H/zENks7+l2Qf85uk Fvie86sPj0k3rh0MQCbilMJtQpkW8yM1R0eL0r+9REeeMpxZ0FNkDgHdTJCuAi99Tq3Sr1 QDD/Ct/vULFBtUikJsNArL3yAULTDIk5PQrJh4xQhYYX5NZfv4zoFQVIVxjXS9179dCPH7 CUnY29Y20y0HFa3Dp4gXmSzcnVbuzVn6dLcd8NW2gAMRQHXPNQiPvu8ZLOuOlQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=aruba.it header.s=a1 header.b=dUrCf+Fr; dmarc=none; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1689335159; 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=FUg86myQ3xcy2KtD42UIVlrNv522EijvTTBFNM/4PMQ=; b=oWbRABG3EYbSx4dwmc+KX7fMYl/8x2p3L21U1DJDW1TvnrY+hmigHkNDBOhDS7UfKdUT3u 0K/qjEtr8xJe5K+X8KTzGQXB6eNFI5xI4hbuiAFOVuC7RAN4TTxgrzovmZSQdGNb5Skok7 svcPGHA0K50kM8MbIbRAwtbvjoDd1o0OhrBcUFMmvBCqvYahSij9kyWl+kryI99eT5hTg/ 6G4ANHiwzNoIRxjLkfFZ7eW/VpM8m1Qi1ISipRoBffb3yWQUM4k0LqDdyIxalofZKLLlAa z66NPVzcuf1DBQuRXvm6xQo805q4A7ALq9lRzFv+xe2VSWlM75YoTCxsMJZYQw== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qKH9q-0001QU-I5; Fri, 14 Jul 2023 07:40:22 -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 1qKH9M-0000l0-Qd for emacs-orgmode@gnu.org; Fri, 14 Jul 2023 07:39:52 -0400 Received: from smtpcmd15185.aruba.it ([62.149.156.185]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKH9J-0004LG-7Q for emacs-orgmode@gnu.org; Fri, 14 Jul 2023 07:39:52 -0400 Received: from fedeli.eu ([10.10.10.166]) by Aruba Outgoing Smtp with ESMTPA id KH9Cqxopcr6FfKH9CqURmk; Fri, 14 Jul 2023 13:39:42 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aruba.it; s=a1; t=1689334782; bh=lv08l0z27997tQkxr9T7SwKz3Pfs9z6uVss71Q079Xg=; h=Date:Subject:MIME-Version:Content-Type:From:To; b=dUrCf+FrhG3PabI/A2rIETn96buxKUxWY5jgN6Ra4hYCSdLex5+HWVCMEZFMRm58i pNAKyK22kFyefvGGlsdb8qjJkWRMWpwYr3H45Ur+DKY8vCUH/EM5YhxgpgVlDPVcZa knNfmS3KDEFhmREfb47Cx3yYqj0fWqgMTatl2HPD+PgO/Srnes+0+z9QCBCL2E925t +vkqq+n6biJCb6yEhM1pLWNTgr6RSAS3hXXqoncOJKIPkp+kul1EszSza9+z31FVvM JaEwd2pIrAqRwyJQkv1rmDkTm7GsWRwwcXu/p9VXoj1oPCLXFv8PwUcCZysqlw3o7R thhVswC04GWZg== Date: Fri, 14 Jul 2023 13:39:42 +0200 Message-Id: In-Reply-To: <87mszyj27n.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?= Subject: =?utf-8?b?UmU6IFtCVUddIEVycm9yIGluIGRhdGEgaW5wdXQgYW5kIG91dHB1dCBm?= =?utf-8?b?b3JtYXQgZm9yIG9yZy1jb2x1bW5zLS1zdW1tYXJ5LWVzdGltYXRl?= MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: multipart/alternative; boundary="_=__=_XaM3_.1689334782.2A.498106.42.18333.52.42.007.1842969467" From: andrea@fedeli.eu To: yantar92@posteo.net Cc: emacs-orgmode@gnu.org X-XaM3-API-Version: 4.2.87.1 X-TipoRicevuta: completa X-type: 0 X-SenderIP: 188.12.198.247 X-CMAE-Envelope: MS4xfBh3Oqv9H2P5NPWh9Bn//M9RTr5HlEk4SXwLm3/ZRM2f0FTcuOhTlei+3dv5P05GcBDrQZsZ4ELmsFC/ZT5w+WVPckWzz+gS9L2WEk7FRGQBhwO9utCt SH1cRjNFyRZ80k4jQsCCqzCplfZ/0Ow5l8rx/hQcKnEA5tKZJbtrtvCSqf1yLW+gJZQ5Bt1JxKz/3romxCcpnQsnk3eU15Vxniw= Received-SPF: pass client-ip=62.149.156.185; envelope-from=andrea@fedeli.eu; helo=smtpcmd15185.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, T_SCC_BODY_TEXT_LINE=-0.01 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-Spam-Score: -7.25 X-Migadu-Scanner: mx2.migadu.com X-Spam-Score: -7.25 X-Migadu-Queue-Id: E2BBA4BD82 X-TUID: 0WM7/5vQspyi --_=__=_XaM3_.1689334782.2A.498106.42.18333.52.42.007.1842969467 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A Howdy!=0A=0A Da "Ihor Radchenko" yantar92@posteo.net=0A A andre= a@fedeli.eu=0A Cc emacs-orgmode@gnu.org=0A Data Fri, 14 Jul 2023 09:0= 2:04 +0000=0A Oggetto Re: [BUG] Error in data input and output format f= or org-columns--summary-estimate=0A [ Adding Org ML back to CC. Please = use "reply all" to reply on the=0A mailing list ]=0A=0A "andrea@fedel= i.eu" writes:=0A=0A > I do apologize, I noticed only= now the patch content: the output=0A > format of duration-from-minutes= Is controlled by the=0A > org-duration-format variable, so if the user= wants results in=0A > months (s)he can easily get It that way.=0A=0A = `org-duration-format' is controlling many other aspects of formatting.=0A= Customizing, for example, agenda should probably not affect column vie= ws.=0A AF: I think we need to univoquely clarify which unit is to be us= ed 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 f= or computation reason; maybe we may introduce a new format variable for e= stimation results reporting. I thought I might use org-duration-from-minu= tes for that, as it came very handy.=0A > About possibile abuses, org d= ocumentation, to date, clearly tells=0A > org estimate utilizes times.=0A= =0A May you please elaborate?=0A AF: Sure! Clause 8.5 of current (202= 3.Jul.14) org documentation, https://orgmode.org/manual/Effort-Estimates.= html, refers to effort estimates giving examples that are all appearing t= o fall in time domain. In particular it refers to org-duration.el for for= mat information. That, IMO, establish that efforts have to refer to org-d= uration units. Now, the *default* values of org-duration are *clearly* ti= me measures. From there my assumption about the fact that I may use the o= rg-duration-to-minutes and org-duration-from-minutes adapters.=0A Clear= ly, you /may/ decide to completely redefine the org-duration basis, but t= hat would mean to coherently propagate the information change everywhere = somebody used org-duration-units which, even though LisP is a very flexib= le language, is NOT what I'd expect org-duration utilizer always foresaw = to have to be flexible in terms of.=0A > Similarly, I'd not spend too m= uch code to check the format; i=0A > understand the intent to preserve = backward compatibility, bit if=0A > that format adaptation mistake slip= ped 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 = Because this way you persist in allowing a mistaken usage of that funct= ion. 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 m= y opinion NOT helpful to any user.=0A The pcase matches either value pa= irs or single values, and org-duration-to-minutes can be charged to decid= e on what to do if values did not match the proper format (with the defau= lt assumption, I'd say, that simple integers are minutes).=0A In facts = org-duration-to-minutes already has a cond classical closing (t ...) bran= ch to deal with that case. I'd leave the rest as I suggested; maybe, if y= ou --as maintainer hence exposed to the global amount of supports request= and use cases-- see that as convenient, with a different output format a= dapter than the one I picked (org-duration-from-minutes without an extra = format specification actual argument); already allowing a custom format a= dapter would introduce an extra flexibility knob BUT consider that org-du= ration-to-minutes does NOT do the same (it implicitly utilizes the org-du= ration-format content, and has hardcoded assumption on quantities being r= epresenting times, so there too you'd need to change something, if it was= not just a matter of definining a different alternative to display resul= t times).=0A Cheers!=0A Andrea.=0A=0A --=0A Ihor Radchenko // y= antar92,=0A Org mode contributor,=0A Learn more about Org mode at .=0A Support Org development at ,=0A or support my work at = =0A --_=__=_XaM3_.1689334782.2A.498106.42.18333.52.42.007.1842969467 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Howdy!


Da "Ihor Radchenko" yantar92@posteo.net
=0A
A andrea@fedeli.eu
=0A
Cc emacs-orgmode@gnu.org
=0A
Data Fri, 14 = Jul 2023 09:02:04 +0000
=0A
Oggetto Re: [BUG] = Error in data input and output format for org-columns--summary-estimate
=0A
=0A
[ Adding Org ML back to CC. Please use "= reply all" to reply on the
mailing list ]
=C2=A0=
"andrea@fedeli.eu" <andrea@fedeli.eu> writes:<= /div>
=C2=A0
> I do apologize, I noticed only now th= e patch content: the output
> format of duration-from-mi= nutes Is controlled by the
> org-duration-format variabl= e, so if the user wants results in
> months (s)he can ea= sily get It that way.
=C2=A0
`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 estimat= ion. As shown below org documentation suggests time it to be used for tha= t, from there it cames the idea to turn times into minutes for computatio= n reason; maybe we may introduce a new format variable for estimation res= ults 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.
=C2=A0
May you ple= ase elaborate?

AF: Sure! Clause 8.5 of current (2023.Jul.14) o= rg documentation,=C2=A0https://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 in= formation. That, IMO, establish that efforts have to refer to org-duratio= n units. Now, the *default* values of org-duration are *clearly* time mea= sures. From there my assumption about the fact that I may use the org-dur= ation-to-minutes and org-duration-from-minutes adapters.

Clear= ly, you /may/ decide to completely redefine the org-duration basis, but t= hat would mean to coherently propagate the information change everywhere = somebody used org-duration-units which, even though LisP is a very flexib= le language, is NOT what I'd expect org-duration utilizer always foresaw = to have to be flexible in terms of.=C2=A0

> Similarly, I'd not spend too much code to check the format; i=
> understand the intent to preserve backward compatibil= ity, bit if
> that format adaptation mistake slipped for= ward to these days I
> doubt that nice feature was used = much so far...
=C2=A0
Yes, but it is easy to have a f= allback, 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.5= ton 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-duratio= n-to-minutes can be charged to decide on what to do if values did not mat= ch the proper format (with the default assumption, I'd say, that simple i= ntegers 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 maintai= ner 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 specific= ation actual argument); already allowing a custom format adapter would in= troduce an extra flexibility knob BUT consider that org-duration-to-minut= es does NOT do the same (it implicitly utilizes the org-duration-format c= ontent, and has hardcoded assumption on quantities being representing tim= es, so there too you'd need to change something, if it was not just a mat= ter of definining a different alternative to display result times).
=
Cheers!

=C2=A0 Andrea.
=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>
--_=__=_XaM3_.1689334782.2A.498106.42.18333.52.42.007.1842969467--