The text is: ^include(“A title here”)^ and yes, “Fiche” is a copy of “MD note root”.
My file is attached to this message. I must have made a mistake somewhere. Thank you for your help.
Essai.tbx (95.5 KB)
Great to see these examples of Markdown export. I hadn’t noticed the introduction of the TextMarkdown attribute.
Based on your file, what works for me here is this:
- Select the note named ‘Manuscrit’ and assign the ‘Fiche’ prototype.
- With ‘Manuscrit’ still selected, in the inspector (command-1) find the Edict tab and click ‘Run Now’.
- Change the text of the note named ‘Export stub’ to ^include(“Manuscrit”)^
I get this result:
This configuration works, thank you, but in this case, Introduction becomes of level 2. However, I need it to be of level 1. In fact, the note called Manuscript is not a chapter or a section. It is a container that has to contain chapters and sections.
OK, the reason your earlier trial failed for the export stub was because its ^include()^ sated the container name as in my original demo “A title here” but you’d renamed the latter to “Introduction”. This underscores my earlier point of changing one or a few things at a time and checking. That way if the change breaks it’s generally easier to figure out what broke. Above, we’d discover we were calling a note “A title here” that no longer exists. So, if we fix the export stub’s $Text:
^include("Introduction")^
We get:
Corrected file: Essai2.tbx (95.6 KB)
But, if you want the export stub to export all 3 outline branches as a single Markdown,
Then the stub’s $Text is this:
^include("Introduction")^
^include("Développement")^
^include("Conclusion")^
Demo: Essai3.tbx (97.0 KB)
Or, if you want 3 *discrete stubs, one for each source branch in the outline:
Demo: Essai4.tbx (97.0 KB)
Even if only building/coding for your self, it can help to write down when you plan. That act forces you to resolve ambiguities in the description that the mind’s eye happily resolves (as the ‘know’ the answer in that moment. But code is less flexible, it wants a description where the implementation or outcome leaves no room for guesses.
Still, I hope the demos above show how little effort is needed to adjust things , albeit once you know what to adjust.
2 Likes
Thank you from the bottom of my heart for all this work! I have one last — I hope — question: if I want to add numbered sections to my document, how should I do it? The one I wanted to add is not numbered. Am I missing again something?
It’s worth noting a nested assumption here. There are potentially two ways to think of export:
- Whole document. File menu → Export → as HTML†. The exports everyone configured to export to a target folder selected on first use. That folder is then the default for the next use but can be altered. IOW, once set, the least-used location is the document’s default.
- Individual Note(s). File menu → Export selected note[s]. The selected items are exported to their position in the whole-doc export (see above). But for root-level notes the user can choose a new location (and also filename/extension if needed)‡§. For instance you might be exporting the whole document as an HTML website but want specific output is other formats which need to be saved elsewhere. Very flexible, once you’ve used it a few times and got a feel for the differences.
†. Note we use the ‘HTML’ option even if our templates are constructed to export, Markdown, CSV, JSON, etc.
‡. Indeed, this makes it really easy for a task of updating a single note’s HTML file in aTbRef. Edit the note. Export selected file and it goes to the right place .. is if I’d re-exported the whole document (which long ago is what one would have had to have done.)
§. Note that it is only root-level notes that ofter the ability to save elsewhere. This is why the export stubs in the demos above. It is also why I advise people doing long-term work 9i.e. not just tinkering) to put their map/content inside a root level container, leaving the root clear for things like template container, export stubs. aTbREf gives a mature example of this, below,: imagine the mess if the room level also contained the top layer of aTbRef content.
By manipulating my file, I think I understand: I need to launch (“Run now” in the Edict section) the MD root note — “Fiche” in my file.
In you But, your example document has no ‘Perspectives’ note. The screen grab doesn’t show the source of this info or the code used. 
Argh! I missed—because $HeadingLevel had already been set—that you were building off my demo but have deleted the prototype that sets the $HeadingLevel for each discrete ‘report’, e.g. Introduction/Développment/Conclusion should all have a prototype that is missing.
… have to stop for lunch, answer in a bit!
If you don’t want ‘Manuscrit’ included and want the notes within it bumped up a level, another simple way might be to make these small changes:
- Make sure ‘Manuscrit’ has the ‘Fiche’ prototype and that the Edict has run.
- Change ‘Markdown page’ template to include just this one line:
^children(/Templates/Markdown page/Markdown item)
- And in ‘Markdown item’ template use $HeadingLevel-1 where you see $HeadingLevel (i.e. subtract 1 so you get one less #.
Result:
I too look forward to Mark’s suggestions for adding section numbering (not usually included in Markdown, but sometimes useful)!
1 Like
So, we’ll put back the prototype that sets heading level, so we’ll add a prototype"Petite racine"† (‘little root’). Important to note customisations:
- it uses prototype ‘Note’ as its prototype. Why? So the these ‘root’ containers can still show (inherit) the Displayed Attributes ($DisplayedAttributes) set for prototype ‘Note’.
- it has an edict set. The job of the edict is to (re-set) the $HeadingLevels for this container and all its descendants. Move the container, or change its descendants? Just trigger the prototype’s $Edict and all $HeadingLevel values are updated for that outline branch. N.B.: the Edict in the container’s prototype does all the work, no need for child notes, etc., to run any code.
- the OnAdd sets
$Prototype="Note";, so all children set the prototype ‘note’. - it gets the $HTMLExportTemplate, for the containers using the prototype, to “Markdown page”. as the export cascade calls child content specifying the template to use (“Markdown item”) there is no need to set an export template explicitly in the descendant notes. Neat!
For the prototype ‘Note’:
- the OnAdd sets
$Prototype="Note";, so all children set the prototype ‘note’.
I have added a badge to each of these two prototypes but only to help testing. Feel free to remove/alter them in your own use.
I also added a new ex ‘Perspectives’ note at path /Manuscrit/Quelque chose/Perspectives with a child note Esprit d'escalier just to flesh out the test. Note that ‘Perspectives’ is deliberately at a different $OutineDepth to ‘Introduction’ so as to test the Edict code in the ‘Petite racine’ prototype. I also added a line in the $Text of ‘Stub d’exportation’, thus:
^include("Introduction")^
^include("Développement")^
^include("Conclusion")^
^include("Perspectives")^
Result:
I think I’ve now covered a few holes in moving my idea into your framework. Question still welcome! Her’s the file: Essai5.tbx (99.5 KB)
†. I hope that is a fair translation. I’m just trying to avoid more unintended errors when replacing my English examples with French-named ones. as my schoolboy French is a bit rusty, I’ve used Google Translate, so I hope it makes sense.
Thank you for your suggestions. The way I use Markdown includes the principle of automatically numbered sections.
It works perfectly. Thank you again for your patient support. This setup will allow me to use Tinderbox and RStudio together and dynamically.
“Petite racine”, it sounds nicely in French. 
1 Like
Good to hear and this is the fun of communities like this, to share with others.
BTW, we’ve run several meetups on this, e.g., Tinderbox Training Video 53 - Working with Markdown and Templates in Tinderbox. Be sure to review the complete video library, there are several templates you can download.
1 Like