Includes does not render markdown when fragment is a variable

[yucheng11122017]

Please confirm that you have searched existing issues in the repo

Yes, I have searched the existing issues

Any related issues?

No response

Tell us about your environment

Windows 10

MarkBind version

V4.1.0

Describe the bug and the steps to reproduce it

When using includes with hash, markdown is not rendering correctly

This is seen in the UG reader facing feature for classes attributes and identifiers and questions.

Expected behavior

Expected markdown to render correctly when using includes

Anything else?

Remove documentation in UG introduced in #2258 regarding this bug if fixed
No response

[damithc]

@yucheng11122017 The common reason for this problem is the lack of a blank line just above the start of the markdown text. I assume that's not the case here?

[yucheng11122017]

@damithc, nope. I tried adding lines and it still doesn't work.
Also, the content in the includes does have the blank line but doesn't render.
I believe the issue is that when the hash is used, the code doesn't do a markdown render again after so changing that part.

[damithc]

@yucheng11122017 I see. Thanks for checking. Looks like a regression that was introduced after the last release (i.e., I have not encountered this before).

[yucheng11122017]

Its probably an edge case.. because it works most of the time. Not 100% sure of the cause yet and will update when I find out :)

[jovyntls]

Might be an issue related to includes boilerplates - hashes in includes, and hashes in nested includes, seem to be rendering correctly.

[yucheng11122017]

@jovyntls Oh yes I think you are right! I think the markdown doesn't render because the code is within the variable for the include. Hence when it is extracted, it remains as text instead of markdown.

Eg.

<include src="codeAndOutput.md" boilerplate >
<variable name="highlightStyle">markdown</variable>
<variable name="code" id="list-example">
* Apply to the list item itself like so {.text-success #list-item-id}
  * Curly groups after newlines apply to the closest nested list {.text-danger}
{.bg-light}
* Curly groups two lines after the last line apply to the top most list

{.alert-info}
</variable>
</include>

The list-example will not get rendered and hence when it is extracted out, it will just remain as text.

I don't believe that we would want to change this behavior as well.

I've been trying to change the order to do the markdown rendering after the taking out the part of the hash but this will result in some issues

• Trim does not working properly with this ordering
• An additional <p> tag is added if inline option is not enabled

Would this issue be worth fixing?

[jovyntls]

Would this issue be worth fixing?

I believe so! It would be nice to polish how we handle includes since it's one of our more powerful features.

The issue appears since v3.0.0 when I serve locally 🤯 Seems to be quite an edge case; would still be nice to fix eventually

[yucheng11122017]

Closing as it is specified in the UG that fragment include only works if the fragment is wrapped in div or span. ie variables are not included by default for this.

May be nice to include this in the future but for now, not a problem :)