On tiddlywiki.com or an empty html create a tiddler and place the following in it;
something {{}}
- “Something” will be repeated many times
- when I had a second line it went for ever and got an awe snap loosing data
1 Like
If it’s of any help, that problem was introduced in some version after TW 5.2.3.
The test case applied in TW 5.2.3
That’s a bug in my view.
I’m currently waiting on this to recover (if it ever will)
Wow. That was scary as hell. When it eventually recovered, I closed the preview pane not noticing at that moment, the source pane was empty.
Then I looked at the other tiddlers in the Story. None were in editing mode. All, when opened, were empty.
EMPTY. TiddlyWiki was showing a red save icon, so I closed the wiki without saving. Reopened and I THINK all is fine.
Not kidding, I sh1t a brick there…
I expect it is defaulting to transcluding the current tiddler, which transudes the current tiddler…
I just tried with a space inside and the loop occurs too.
- This would be an expected and good outcome!
And a SLOW loop… my messages attest to 8 minutes. About 12 in total, I reckon.
And no RSOD… jeez.
See this comment at GitHub [BUG] $:/core/ui/PageTemplate/story Caught in a dead loop on entry · Issue #7579 · Jermolene/TiddlyWiki5 · GitHub
No. The first paragraph of @jeremyruston comment explains what is different between v5.3.x and v5.2.x
The PR that I made only takes care of the core UI view and editing problems. It does not prevent the UI to get unresponsive if there are problems with uninitialized variables or empty transclusions while developing your own “code”
@jeremyruston – I think the MAX_WIDGET_TREE_DEPTH variable is still at 1000. IMO it depends on the computer and may be available memory for the browser, if it “survives” problems with empty transclusions.
In the end the UI seems to be “bricked” even if it may be recoverable, if you know, what’s going on.
I personally think that the UI is much more vulnerable to code typos since v5.3.0 where the new mechanism was released.
@TW_Tones IMO you should open a new issue at GH with a reference back to this thread.
1 Like
This x 1000. Significant downgrade in UX. The preview pane is now too volatile to trust for “code” work.
For safety reasons in post 5.3.0 wikis, I use code-body: yes whenever I am experimenting with new untested code. I have experienced browser slow down many times post 5.3.0.
yeah, i have also noticed many more levels of recursion in transclusions now vs 5.2.X, which is not desired - it takes a lot longer before giving the recursion error. before, it was pretty quick so the wiki would stay responsive when you accidentally made an endless loop. now it just freezes up and i have to quit without saving to fix it.
even just making a filtered transclusion - with codemirror autoclosing brackets you have to go through {{}} and {{{}}} to start one, and the latter gives me this:
surely it didn’t need to take that many loops to error out? it didn’t in 5.2.X:
this is much more impactful when there is other content in the tiddler like widgets or filters that has to be recursed many times.
I’m considering turning that off. It’s mostly annoying anyway. Its detection for " → "" is 100% wrong/unhelpful for me, anyway.
Me too… wasn’t sure what to put it down to.
Thanks @TW_Tones there are two issues in this thread:
- That
Something {{{}}causes a recursion error - That the recursion error is trapped much later in v5.3.x than in previous versions
I’ve posted a PR that fixes the first issue - Ensure {{}} doesn't cause a recursion error by Jermolene · Pull Request #7768 · Jermolene/TiddlyWiki5 · GitHub
To address the other problem we have two choices:
- Reduce the “depth” limit at which recursion errors occur (currently 1000). The risk is that legitimate constructions might trigger the lower limit (ie “false negatives”)
- Re-introduce the old recursion detection algorithm. The problem with this is that there are legitimate constructions that trigger this warning (ie there are “false positives”)
is it possible to make recursion depth an (advanced) control panel setting, set lower by default? that way, it will not cause issues for new wikis or for new users learning about transclusions. if someone runs into false errors, they can increase the limit - they are likely making some advanced construction and would know what they are doing by doing so.
4 Likes
@CodaCoder Can you try your code with the preview at: https://tiddlywiki5-git-fix-blank-transclusion-recursi-c57ecb-jermolene.vercel.app/ which Jeremy created with a partial fix.
Seems fine. I tried hard to break it…
I broke it with <$transclude/> the long hand version of {{}} comments in GitHub.
- Also the proposed fix seemed to already have being applied, to tiddlywiki.com and prerelease, which surprised me.