emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: columnview dynamic block - different time summing behaviour for EFFO


From: Alexander Adolf
Subject: Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM
Date: Fri, 12 Apr 2024 14:13:48 +0200

Hello Ihor,

Many thanks for your swift response.

Ihor Radchenko <yantar92@posteo.net> 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. 🦄😜


Cheers, and looking forward to your thoughts,

  --alexander



reply via email to

[Prev in Thread] Current Thread [Next in Thread]