Macro recursion runs out of control without reason

43 views
Skip to first unread message

Mark Green

unread,
Jul 20, 2020, 4:17:34 PM7/20/20
to TiddlyWiki
For those who have been following my efforts with mod- fields, this is the next chapter - thanks for all the help so far!

Currently, ModifierBlockMacro contains:

\define innermodifierblock(for:"")
$for$
<$set name="x" value=<<__for__>> >
<$set name="mfield" filter="[title<x>lowercase[]split[ ]join[_]addprefix[mod-]]">
<$list filter="[all[tiddlers]has<mfield>]">
<tr><th><$link/></th><td><<x>></td><td><$view field=<<mfield>> /></td></tr>
<<innermodifierblock <<currentTiddler>>
</$list>
</$set>
</$set>
\end

\define ModifierBlock(for:"")
<table>
<<innermodifierblock $for$>>
</table>
\end

Tiddler ModifierBlockTest contains <<ModifierBlock test>> and has no fields.

Tiddler InheritModTest contains no text but has field mod-test: Level1.
Tiddler InheritModTest1 contains no text but has field mod-inheritmodtest: Level 2.

So what should happen is:
<<innermodifierblock test>> runs
It adds InheritModTest to the list because of its mod-test
<<innermodifierblock inheritmodtest>> runs
It adds InheritModTest1 to the list because of its mod-inheritmodtest
<<innermodifierblock inheritmodtest1>> runs
It adds nothing to the list because there is no mod-inheretmodtest1 anywhere
<<innermodifierblock inheritmodtest1>> ends
<<innermodifierblock inheritmodtest>> ends
<<innermodifierblock test>> ends

What actually happens is that TiddlyWiki crashes with an infinite recursion error, constantly repeating the first line of the list with "InheritModTest - test - level1" on it, followed by "InheritModTest" as it indicates the start of the new loop. It seems that it is confusing the two $list s running in different recursive scopes. Is there any way around this?

Mark S.

unread,
Jul 20, 2020, 4:51:08 PM7/20/20
to TiddlyWiki
This line

<<innermodifierblock <<currentTiddler>>

is lacking a closing >> . However, I don't think you can feed a macro to a macro that way. At least I've never been able to. You probably need to use the macrocall widget:

<$macrocall $name="innermodifierblock" for=??? />

I have ??? since I don't know what parameters you want "for" to contain.

Good luck!

Eric Shulman

unread,
Jul 20, 2020, 4:53:59 PM7/20/20
to TiddlyWiki
On Monday, July 20, 2020 at 1:17:34 PM UTC-7, Mark Green wrote:
For those who have been following my efforts with mod- fields, this is the next chapter - thanks for all the help so far!

The logic in your code is a bit hard to follow.  Still... just looking at syntax issues, I note this line: 
<<innermodifierblock <<currentTiddler>>

Even without comprehending the logic, it seems like what you are trying to do is to
invoke the "innermodifierblock" macro with a parameter which is the value of <<currentTiddler>>.

But, the above line has mis-matched angle brackets.  As a result what you are actually
doing is invoking "innermodifierblock" with a literal text parameter of "<<currentTiddler"

What you probably wanted to write is something like this:
<<innermodifierblock <<currentTiddler>> >>

But that won't work either, because you can't "nest" the double-angle brackets
when calling a macro (the parser just doesn't work that way).

To pass the <<currentTiddler>> value as a param, you would need to use the *widget* form of macrocall:
<$macrocall $name="innermodifierblock" for=<<currentTiddler>> />

Again... I'm just noting a *syntax* issue.  It's not clear to me if you have any
logic errors in the way things are coded... but perhaps the above information
will help you get where you are trying to go.

-e

Mark Green

unread,
Jul 20, 2020, 5:33:21 PM7/20/20
to TiddlyWiki
Thanks! That actually fixed it! I wonder why it was recursing at all with invalid syntax?

TW Tones

unread,
Jul 20, 2020, 5:35:20 PM7/20/20
to TiddlyWiki
Mark

Examples that can be installed and work on tiddlywiki.com or empty.html would help us work with you. See how you go after correcting the current tiddler.

In macros the previous current tiddler value is available with $(currentTiddler)$ so you do not have to pass it as a parameter.

Regards
Tony

Mat

unread,
Jul 20, 2020, 7:46:58 PM7/20/20
to TiddlyWiki
Mark Green wrote:
Thanks! That actually fixed it! I wonder why it was recursing at all with invalid syntax?

Prolly because <<recursethis <<withThis>> does also have a closure but it is all the way over here. 

<:-)
Reply all
Reply to author
Forward
0 new messages