Fix ConditionalBlock crash in manuscript projects #13624
+26
−2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
ConditionalBlock in manuscript projects would crash with a fatal error during rendering when using conditional content like
.content-visible when-format.Summary below, more details in
Root Cause
The manuscript filter built block collections using
pandoc.List()and assigned them todivEl.content. This changed the content type from "Blocks" to "List". When ConditionalBlock's render function returnedel.content, it returned a List without a.walk()method.During custom node rendering,
has_custom_nodes()attempts to walk the rendered result to check for nested custom nodes. The AST walker'schecked_walk()function expects walkable Pandoc elements (Blocks, Inlines, Pandoc) and fails on plain Lua tables like List. This guard rail correctly caught the type mismatch.Why Manuscript Specifically?
Default projects don't run the manuscript filter, so Div.content remains type "Blocks" throughout. Only manuscript's flattening logic (which builds new block collections) exposed this type mismatch issue.
Fix
Changed manuscript.lua to use
pandoc.Blocks({})instead ofpandoc.List()to maintain proper type throughout the filter chain.Fixes #13616
A note that this bug was introduced in 1.7 and it was not failing in 1.6. So maybe we should consider backport... 🤔