![]() ![]() So there would need to be file type specific rules regarding transclusion. For example, iA Writer presents the CSV file as a table. There’s also the question of how this information should be transcluded. So there might be a case for using the iA Writer syntax for embedded content with optional captions, rather than hijacking the Markdown image syntax reserved for alt or title to display figures. However, the text in brackets or quotes in the iA Writer syntax is displayed as a caption - whereas in Markdown, alternative text is not displayed as a caption without some non-standard post-processing. For the iA Writer examples, we could use this syntax: !(section.txt) ![]() ![]() In Markdown we already have a syntax for including images, which could be extended for other embedded files. In some ways this syntax is reinventing the wheel. I think the iA Writer syntax is even more intuitive for causal writers than Markdown’s regular image syntax. The use of a forward slash for all transcluded file types is easy to remember. In the link posted, there’s some further examples for transcluding text, tables, and images: /Section.txt "Section" (And note that this does in fact nothing else but replicate the purpose and use of external and internal XML entities in CommonMark.) But the flexibility and consistency that using &ref in these cases too would entail-adopted directly from XML-is worth considering, I would think. Maybe it seems too far a step to use &ref for these tricks too, and it may seem that : would indicate clearer that “something special” is going on here. In the internal subset and then referencing (“transcluding”) this text with literally the same syntax &ref as given in the example above?Īnd since we have re-invented external entities already, why not re-invent internal entities, too? Which could look in CommonMark like this: Simple extension: insert &here some internal entity. While the second case (the inline URL) looks pretty ugly and error-prone to me.Īnd why shouldn’t we be honest and admit at this point that we re-invent external entities in CommonMark- the exact same thing that in XML would be done by placing Now the first case looks suspiciously close in intent, syntax, and behaviour to Existing syntax: &ref in _CommonMark_ text (via *entity reference*). So a symbolic reference or an in-line URL would be enough, either written as : (with the same “fall-back” property), or as: Simple analogy to indirect link syntax : in _CommonMark_ text.Īnalogy to direct link syntax :() in _CommonMark_ text. Looks reasonable to me, as long as the analogy to CommonMark’s “indirect” link syntax is also taken into account: Simple extension of indirect link syntax : in _CommonMark_ textīut where does the here and Example text to include text strings go, when after all the string : is supposed to be replaced with the “transcluded” text? They would just be discarded and have no purpose, right? The big plus is graceful degradation into links, and possible context passing. Simple extension of markdown link syntax :(link.md) (preceding colon :) ![]() I think the first form is quite true to the spirit of the markdown, I’m a little biased about the second form because I’ve written too much python, and the third form could make sense if CommonMark supports anchors (not sure if it does).Īs for it being an extension, I do think this feature can be generically useful. will only include the lines 2 to 4 in the local scope of the given symbol. I have implemented this in a code documentation tool I’m writing, with the following syntax: I don’t agree that “the resolution of the transcluded document name inherently domain-specific.”, if the “inclusion target” is specified to be a file name. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |