I’m currently working with Tinderbox and trying to leverage the “explode” feature to break down one larger note into multiple smaller notes. The issue I am encountering concerns the way Tinderbox handles Markdown syntax, particularly the headings (markdown #).
When my note contains Markdown-style headings (e.g., # for H1, ## for H2), Tinderbox seems to interpret these symbols incorrectly, possibly treating them as tags or metadata, rather than as heading indicators. As a result, parts of my content either disappear or get misinterpreted, affecting the structure of the exploded notes.
Has anyone else run into this issue? Is there a particular setting within Tinderbox that I should disable/enable to have it correctly handle Markdown syntax? Alternatively, does anyone know of a preprocessing step or custom templates that can help Tinderbox recognize the headings and avoid treating them as other types of data?
As an example, I may have a note like this:
# Heading 1
Some content here.
## Heading 2
Additional content under heading 2.
[Edit by froum admin: fixed code section mark-up to remove syntax mis-colouring]
And after attempting to explode it, the structure doesn’t come out as expected, and some content seems to be lost or assigned incorrectly.
Any tips, workarounds, or recommended best practices you could provide would be appreciated!
I fixed the Markdown in the code in the original post - the italics are an artefact of the forum software auto-guessing the code ‘language’ in the code block.
Tip: when making a code block like the one above, we add 3 backticks on a discrete line before and after the code. To suppress syntax colouring, on the first line of back-ticks add a space and then the word text and the code will be shown in a code-style font but with no colouring.
It’s not a but, but a feature! The villain here is the doc setting to detect prototypes in note names. Turn it off (un-tick box in Doc Settings—use Cmd+8, General tab) and all works.
The issue is not, as it appears to be, an error in Explode. Rather, the correct note title is made but the above setting detects a # (from character 2 onwards) and makes a prototype as per that above feature:
Not what we want! Disabling the prototype detection feature will fix the problem.
Oh dear, this feature catches me out every time and if I could I’d auto set it to off for all new docs but that’s not possible. Here, it wasted a good 20 minutes today testing and documenting tests before I hit on the actual cause, i.e. not a bug in explode—but arguably a bug in prototype detection!
I have a Feature Modification suggestion (for consideration), change the app default for the prototype detection to ‘off’. My rationale: it’s an edge case feature, very useful for the some who want/need it but otherwise it causes (apparent) bugs in other general operations. In the narrow case here, I suggest the feature’s parser first ignore all contiguous # (1 or more) from the start of the title string and only then look for prototype-hinting mark-up. I do respect the dev’s challenge that new features that are ‘off’ by default are less discoverable. However, this is sufficiently edge case as to not be something one would intuit as being available and world need to look it up to know it was there—in which case the default setting choice doesn’t need to be ‘on’. It being off has a les harmful effect, i.e. a prototype or place is not made but that should be immediately apparent, and its cause.
BTW, in addition to turning off the # prototype creation setting, here is another tip. Use the RegEx beginning of the line anchor ^. That way you match only one, two, or three #s, etc. See below
This is because ^ is matching the beginning of the source string (i.e. all of $text) not the beginning of each line. Better, if you do want to break at headings is to use delimiter pattern #+ (i.e. one or more consecutive hashes). If you opt to delete the delimiter you get:
But, this will also match any hashes anywhere in the text.
One option if you want to break headings and retain Markdown is to use BBEdit and replace all ^# sequences (here ^does match line start) with something like §# so our source looks like:
§# Heading 1
Some content here.
§## Heading 2
Additional content under heading 2.
Then, turning $Prototype detection off " and choosing:
