From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id KEJDL7ElGWaVVQEA62LTzQ:P1 (envelope-from ) for ; Fri, 12 Apr 2024 14:14:41 +0200 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id KEJDL7ElGWaVVQEA62LTzQ (envelope-from ) for ; Fri, 12 Apr 2024 14:14:41 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=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"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1712924081; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=ihUF4mcgoucqMzdoQqW/FxcgBqlUjTa+1mGXnuLmoBU=; b=KN3DqlNB8wwS0FB1IpynzTEpAux21C2VYoUr+/w84ac7cu8GU7uICWOgKVaSqulvixCyKQ 8zT/WJZ2Qa1EATHCJEE3stPu0NmrZtrYskk3eJO2yy981pz08WzSECGSTaxWVNUY+mHhEO 3kbX4Iq9hArt46+gPIJ22txH2rCjou1ktyd2SGLeDFXK1ZW9wa1dJr3cF3qSw/VyKzDpOR xxc+y8yM2an0iSc5VKmmZOy9Sfey/D0MEkdS75qtDu01WHdCiLN9YGFKaLeK50ahZijU42 4NkWF81sqNA0h2tBcjhuny0HSF4hVq0sulY8YDatdDnP5rpiRSJogm68Q6d9ZQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1712924081; a=rsa-sha256; cv=none; b=pRrKMRzaTJUsRKJ0w1KXGgE7mq9I7gIixJefboB5N9njbz3rHt9ndfhQSy25W43CJWhDym 2oY8fxB4wmwtqiTEL31k9WbThUUk3tMu4Bdy11+Bln7NAmQliVPhLX4m4d8OweSI0eyJgc ITGnCcxOGBKqzYLYFeSB4xdrxpjO3rXM1+/Vnng+6j+75ofxuDmzovLk/Pk7z02lDGV4VD Wc7BDPXsR3UrUEGU3r39VdBOGhRB8Y39KX2N8G3iUUy8QCpWH60ia2xmCGM0iYeMENgieG c294HXcuvIdQy7PgMFhXoL/RdqXsnuR2xvNKVO0ym7sgYTaoLF6wiZMsU8yZvA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=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"; dmarc=none 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 80CB03D0A0 for ; Fri, 12 Apr 2024 14:14:41 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rvFnL-0004Cl-U9; Fri, 12 Apr 2024 08:14:16 -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 1rvFn4-0004AG-Hp for emacs-orgmode@gnu.org; Fri, 12 Apr 2024 08:14:00 -0400 Received: from smtprelay02.ispgateway.de ([80.67.29.24]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rvFmy-0001Cm-U0 for emacs-orgmode@gnu.org; Fri, 12 Apr 2024 08:13:57 -0400 Received: from [185.17.206.205] (helo=condition-alpha.com) by smtprelay02.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1rvFmu-000000003ES-3KHj; Fri, 12 Apr 2024 14:13:48 +0200 Message-Id: <00aa9bf72dc93f6554bdd236fdfba192@condition-alpha.com> From: Alexander Adolf To: Ihor Radchenko Cc: emacs-orgmode@gnu.org Subject: Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM In-Reply-To: <871q7cypxl.fsf@localhost> References: <486d2b818b62c71b3f307305c06c4318@condition-alpha.com> <871q7cypxl.fsf@localhost> Date: Fri, 12 Apr 2024 14:13:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Df-Sender: YWxleGFuZGVyLmFkb2xmQGNvbmRpdGlvbi1hbHBoYS5jb20= Received-SPF: pass client-ip=80.67.29.24; envelope-from=alexander.adolf@condition-alpha.com; helo=smtprelay02.ispgateway.de 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=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: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -3.38 X-Spam-Score: -3.38 X-Migadu-Queue-Id: 80CB03D0A0 X-Migadu-Scanner: mx13.migadu.com X-TUID: nwsEgOaiApLa Hello Ihor, Many thanks for your swift response. Ihor Radchenko writes: > [...] >> Does anyone recall the rationale for this different behaviour? > > The "default" behaviour is to store summary of all the child property > value in each parent. > [...] > This is, however, not possible for CLOCKSUM because clocksum is not an > actual property, but a "special" one - it is derived from logbook data. > That's why its behavior is different. I see; thanks for explaining the rationale. Practically this seems to imply that for doing estimates, and to minimise my own confusion, I should probably use a strategy where I put all the effort properties in a subtree at the same level (for instance leaf-nodes-only, or top-nodes-only). And additionally, I should never modify effort properties by hand, but using the columnview overlay only (since that will not allow me to modify efforts computed from child nodes). > In fact, CLOCKSUM property does not support custom summaries. ??? >> Is there any way to change the summation behaviour for either or both >> column types? > > It is currently hard-coded. (Although, it is not too hard add some kind > of switch). > [...] I think that instead of a switch, I would prefer the columnview dblock to get a :formatter added. Knowing how the values have been computed in the dblock's write function, I can re-calculate whatever data I need in the formatter. I am already using this approach successfully with the clocktable dblock to generate invoices for me. Compared to a new switch, it would seem to me that adding a :formatter to the columnview dblock has several advantages: - it would likely be a smaller code change; - instead of implementing a single, new behaviour (activated by switch) it would give users the flexibility to implement any new behaviour they might want (user-supplied :formatter function). Thus, from my point of view, having a :formatter for the columnview dblock would be quite fabulous. =F0=9F=A6=84=F0=9F=98=9C Cheers, and looking forward to your thoughts, --alexander