there is a little issue with the markdown parsing the string " 1.
"
yes, also true for the html variant of this node.
there’s some unallowed things in markdown/html that need to be taken care of.
i don’t think i could catch all of them (defaults, etc.) and also it would be too much work. so far i don’t have a good strategy for this, except leaving it to the user like wrapping the node in a try region. or replace some parts of the string.
example
in a recent project i replaced all
occurrences in a html string with a CRLF for proper parsing.
at least that is what i guess from a screenshot only. might be something different.
btw. here is a new branch that works with versions >= 6.7-177 without modifying the vvvv install folder.
i can make a nuget out of it but i first want to gather some feedback or opinions here and possibly iron out some bugs.
nah its just the parsing that fails with that string: “1.” (a number followed by a dot) and creates an empty snippet. might have been more precise
the thing is, 1. in markdown introduces a list element. as you can see in this screenshot (or if you have a look into [ParseMarkdown]):
at 1. you see some debug output, which basically shows you which part of the markdown string translates to which style.
in this case it’s an empty string with the style li.
but as you can see at 2., there’s no style defined for li in the style dictionary (as is for text, em, strong and code, therefore those work) and the TryGetValue returns a NULL style.
i could add a keep here to swallow the pink node for example:
but then you might wonder, where is my input?
and because there’s no general solution to this (that i know of) i decided to leave it pinkish for now.
of course, there’s a way to define a dictionary with all possible markdown styles. downside is that there are many… but maybe the most common set would be enough?
not much tested, treat it as a prerelease…
inlcudes a new feature from @Rayment that enables to specify fonts by filepaths!