Feature request -- subtree

[laurentowel]

Since Forester 3.1, there has been support for inline subtrees. This feature removes the strict bijection between files and trees, allowing a single file to contain multiple distinct subtrees via the \subtree command.

Personally, I find the current requirement of "one file = one note" disruptive to the writing process. When expanding on a topic, having to stop and create a new file for every sub-concept (that I'd like to have links to in the future) adds mental pressure and breaks the flow of thought.

Therefore, I would like the ability to define multiple notes or trees within a single file, and I'd like to know

1. Is this currently achievable using either Markdown or Typst?
2. If not, is this feature planned for a future release?

[kokic]

1. No. However, for markdown documents, "inline-section" ¹ can be used to partially accomplish this task (but it is not a true tree and cannot be linked), e.g., https://kokic.github.io/CN2A.
2. You are right. I am currently designing a new format for this purpose. According to the survey, it is highly impractical to perform these tasks in Markdown or Typst specification.

Footnotes

1. An anonymous inline subtree will, naturally, not have its own page emitted and cannot be linked to. In the graph analysis (for computing backlinks, etc.), https://www.forester-notes.org/00O4/index.xml. ↩

[kokic]

There is another possibility: introducing misaligned design. When users need a real subtree, they can only write this part through a typst file. (Of course, links and embeds can also be established between markdown and typst)

[laurentowel]

There is another possibility: introducing misaligned design. When users need a real subtree, they can only write this part through a typst file.

So far I've been using Typst exclusively. I haven't given it much thought, but I wonder why implementing this in Markdown might be impractical -- would something like the following work?

<remark slug="BAR66">
  ...
</remark>

The idea is to treat an inline section as linkable only when a slug is provided.

[kokic]

This issue arises from the incorrect specification of embedded HTML in markdown e.g.,

• CommonMark does not rely on tag matching to end HTML blocks.
• https://spec.commonmark.org/0.30/#html-blocks

If implemented with HTML tags, users may indeed be able to write, but the syntax will become very strange.

[kokic]

https://github.com/kokic/kodama/blob/main/featured-demo/trees/index.typst#L22-L24