Repository navigation
Conversation
7660c69 to
2fe982a
Compare
A role or a substitution in a definition-list term is rendered exactly as the parser created it, while the same role in a paragraph is transformed. The compiler builds its shadow tree from getChildren() only, and DefinitionListItemNode keeps its term and classifiers in properties of their own. Each transformer that works on inline nodes has to walk them itself, as the TYPO3 theme does. The term is not the only such node. Code and menu captions, admonition and sidebar titles, the type, default and options of a confval, the argument of a general directive, the cells of a table, the image and caption of a figure, the target of an image and the parts of a bootstrap card or accordion item are kept the same way, and were just as invisible. A substitution in a table cell, for example, was rendered as "|known|". Such nodes now implement HasAttachedNodes and name the nodes they keep beside their children. The shadow tree visits attached nodes before the children. A change inside an attached node is made in the attached node itself, as its parent keeps it in a readonly property and cannot take a copy. The attached node itself cannot be replaced or removed. Admonitions, sidebars, confvals and cards are built by DirectiveProcessPass at priority 100, after most built-in transformers, so only transformers that run later reach their attached nodes. Resolves #1425 Signed-off-by: linawolf Assisted-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2fe982a to
3d20e12
Compare
jaapio
left a comment
There was a problem hiding this comment.
I do understand the issue, And I completely get why this happens. But I do not really like the solution of a new interface on the nodes. It feels like this is a bit of a hack to create a different flavor for Nodes in the ShadowTree. I'm not sure this will be improved by Introducing a new type, AttachedTreeNode. But it removes a bit of the hacky logic.
What I do not fully understand yet out of this code is how the "Attached" nodes are pushed back into the original node. Because made all nodes immutable, it could be an issue that nodes are never set back on the original Node that carried them?
The textual index seems also bit of an issue, this makes it a really fragile design, which we have to keep in mind when adding new nodes. I'm a bit afraid that this will cause a lot of bugs and issues in the future. Although I do not have a very good alternative right now.
[BUGFIX] Let node transformers visit nodes kept outside the children
A role or a substitution in a definition-list term is rendered exactly
as the parser created it, while the same role in a paragraph is
transformed. The compiler builds its shadow tree from getChildren()
only, and DefinitionListItemNode keeps its term and classifiers in
properties of their own. Each transformer that works on inline nodes
has to walk them itself, as the TYPO3 theme does.
The term is not the only such node. Code and menu captions, admonition
and sidebar titles, the type, default and options of a confval, the
argument of a general directive, the cells of a table, the image and
caption of a figure, the target of an image and the parts of a
bootstrap card or accordion item are kept the same way, and were just
as invisible. A substitution in a table cell, for example, was
rendered as "|known|".
Such nodes now implement HasAttachedNodes and name the nodes they keep
beside their children. The shadow tree visits attached nodes before
the children. A change inside an attached node is made in the attached
node itself, as its parent keeps it in a readonly property and cannot
take a copy. The attached node itself cannot be replaced or removed.
Admonitions, sidebars, confvals and cards are built by
DirectiveProcessPass at priority 100, after most built-in transformers,
so only transformers that run later reach their attached nodes.
Resolves #1425
Signed-off-by: linawolf
Assisted-By: Claude Opus 5.5 (1M context) noreply@anthropic.com