I’m pasting this directly from Gemini teaching me but I’m very new to TiddlyWiki and Windows. I searched for subcategories for this but didn’t immediately f>be that. Gemini instructed to jump to developer but I thought I’d try “here” first. Unsure relative tags, can they be updated?
Gemini report:
CRITICAL BUG: JSON Array Iteration (jsonget$/:map) and WikiText Conflict (v5.3.8)
Section
Detail
TiddlyWiki Version
5.3.8
Operating System
Windows 11
Running Method
TiddlyDesktop
Primary Failure
The complex filter required to read and iterate a JSON array (jsonget$ :map) either fails to execute or outputs malformed text, causing subsequent WikiText rendering failures.
JSON Iteration Failure (Test 1): The filter does not generate the two expected rows (Apple/red, Banana/yellow). [Gemini really wrong — renders as: |!Fruit|!Color||:—|:—| saparate lines doesn’t JSON], or the entire block fails to render correctly, confirming that the complex filter syntax is broken in this version/environment.
WikiText Conflict Failure (Test 2): [I’m wrestling hard with Gemini — it says failure with confusing logic of table on same line as JSON failing but JSON failing either way and contradictory to AI the table renders by itself normally].
Gemini says JSON should work by itself but it’s prepared to walk me through plugins (syntax I don’t want) or node.js as server which is interesting but something else and I’m not too familiar with Windows. Gemini too much focus on table…
In your markup, you are trying to have the $list widget generate multiple table cells as output. To make it work, you need to use HTML table syntax. Also, the json filter syntax provided by Gemini is horribly wrong (LLM’s have absolutely NO CLUE about how to write TiddlyWiki code. It’s like giving a monkey a gun… it’s just a really bad idea and someone is gonna get hurt!)
The $list widget gets the array indexes from the JSON data. Note how {$:/BugReport/JsonData} uses curly braces… this gets the text content from the tiddler. The json filter operators need the tiddler’s text, not the tiddler’s title.
Next, for each index, the $let widget extracts the corrsponding JSON object (e.g., {"name": "Apple", "color": "red"})
Then, we output a table row:
the first cell gets the object’s “name” attribute and shows it as plain text
the second cell gets the object “color” attribute and shows it as plain text
I kept using Gemini because that’s just been my workflow, I’ve spent all 3 nights since installing just to begin to explore the psychology of this atomization however it is decided the jargon and syntaxes. We also were on the verge of going from having Gemini take your suggestion literally, to resulting in 4 “reds”, to a malformed table of 3 colomns with data maligned from headers but just before allowing it to take us to the node.js path, with all the logic figured out, the only problem was to remove every single space (no, duh — early webmastery was like that). So what worked for me (as I still cringe that a non-html solution wasn’t available):
In Discourse, when you want to show HTML code (or ANY content that occurs between < and >), you need to enclose that code between lines that have tripled backquotes (```). This prevents Discourse from attempting to render it as HTML syntax, and instead shows it as regular text.
You have very high expectations for table markup. Is there some other application or technology that will allow you to create dynamic content inside of table markup?
Using node.js will not change how table markup works. Wikitext is the same for the single file version of TiddlyWiki as for the node.js version.
Eric presented a working solution. You can copy paste that code to Gemini and tell it, that it works that way. It should accept it and work with it.
As Eric pointed out. The forum here uses Markdown syntax, which is OK. But still you should cover code snippets or code blocks in single and tripple backticks.
I did modify your OP, to show code snippets, that we need to reproduce your usecase.
The problem with Gemini is, that it thinks TW uses Markdown syntax for tables. That’s not the case. TW wikitext looks a bit different. See: Tables in Wikitext (Which can not be used for your usecase)