I’ve had a similar challenge over the years, but just thought of a different idea/approach that seems to make a lot of sense to me.
Because a lot of what I do with project management involves dates, I have to rely a lot on javascript macros to do date math. There are many such javascript macros out there. I’ve taken add-time and date-diff from @inmysocks and modified for my needs for instance.
The issue is that (as far as I know) there’s no way to “use” the value returned by a <$macrocall>
widget right now other than store it in a macro and use a <$wikify>
to store it in a variable. Minimizing the use of <$wikify>
is a common suggestion for performance reasons, I’m curious if extending the <$macrocall>
widget to work like a <$list>
or <$set>
/<$vars>
where the “content” can expose a variable to be used - either within filters or anything else is a good idea.
In case that was confusing, here’s an example of what I’m suggesting…
Today (pseudo-code):
\define new-date() <$macrocall $name="date-add" basedate={{!!date}} days={{!!days}}/>
<$wikify name="new-date-wikified" text=<<new-date>>>
<$list filter="[tag[Task]due<new-date-wikified>]">
</$list>
</$wikify>
Would become:
<$macrocall $name="date-add" basedate={{!!date}} days={{!!days}} variable="new-date">
<$list filter="[tag[Task]due<new-date>]">
</$list>
</$macrocall>
There are other things I’m considering for this specific use-case around dates. For instance I think a long time ago @saqimtiaz suggested making a filter operator out of these date macros which does make sense, and the ability in 5.2.0 to use parameters within macros in filters helps too, but independently the <$macrocall></$macrocall>
thing seems useful too. Just curious in thoughts from the devs on the idea.