Inspired by @Scott_Sauyet , I realized we could use lists for transclusion.
Here’s the link to my solution. I used a procedure to solve the problem.
Below is @Scott_Sauyet’s original post.
Deriving wiki structure from titles (long) - Discussion - Talk TW
It’s very interesting to me that this is your takeaway from that. I didn’t even think to specifically call out that part of the design, as I use it all the time. But you’re absolutely right that it may be a new technique for many users.
Very nice! Overall, it reminds me of my first approach, using tags (and other fields) to describe and render the hierarchy. That approach also originally had the equivalent of transcludeChildren1 and transcludeChildren2; as I found commonalities there, I refactored them into the type parameter to my children procedure. (Which evolved into the structure field used in the refactoring.)
In the thread you refence, I describe what I think of as a more evolved version of this pattern, deriving as much of this information as possible from structured titles. There are good reasons for that, but they won’t apply to most cases.
This is very nice. I’m curious, do you currently have practical needs for this technique?
I probably don’t think about automation much. Right now, I’m just a documentation user. Before, I was clumsily using {{xxx}}.
I’ve learned about nested procedures.
I believe we need a macro similar to the toc macro to transclude all hierarchical content, generating a linear document. This can then be used for printing or generating PDF documents.
PDF documents are a more widely accepted format than HTML. Compared to clicking through content, most people are more accustomed to flipping pages or scrolling through linear documents. People primarily need linear documents, and only secondarily need linear documents with clickable tables of contents. When sharing documents with others, I often worry recipients won’t read wiki documents.
Some advantages of PDF over wiki documents:
PDFs are acceptable in instant messaging, whereas HTML poses barriers.
AI systems accept PDF documents but reject HTML and wiki documents.
From a publishing perspective, PDF is more universally compatible than HTML.
HTML involves various interactive interfaces, while PDF is simple enough for everyone to read without barriers.
I will post the above points in a separate thread.