I believe in inter-operability or some universal standards in all notes apps. OPML seems to be the preferred format.
But some other note-taking apps I use that support local MD files. So I want to export Tinderbox project files in a way that each note is exported as an individual MD file. Not sure if this is possible to recreate in Tinderbox or with OPML export using some other app.
Let me know if you guys can help or have the same issues?
I think that is a false assumption, presumably based on seeing some app offer the same range of interchange format(s). That doesn’t create a standard in other but the loosest sense.
We a background in doing inter-app data migration, my take on standards is trust no app until the transfer is tested and don’t assume the app you understand better is the ‘good’ one if the transfer fails in some way.
OPML is a good case in point. As noted at opml.org the format has been around since 2000 but few apps offering OPML import/export use the defined standard (here†). Instead, most use Omnigroup’s (undocumented?) fork of the standard OPML as they popularised via OmniOutliner. So if your favourite app is using OPML, it’s highly likely you aren’t using the ‘standard’ OPML but are actually using the Omnigroup flavour of OPML possibly with other non-standard changes. This is why is it dangerous to use the term ‘standard’ when we really mean ‘common interchange format’.
Markdown is the same but sadly, even more fragmented. Like any religion it has a number of non-compatible sects each with conflicting beliefs, i.e. incompatible format assumptions. This is reflected by the fact that Tinderbox bundles two (of the many) Markdown flavours as the app can’t know what any given users ‘normal’ Markdown is.
So, having addressed the slippery-ness of ‘standards’, let’s turn to Tinderbox export:
Yes it is possible, absolutely! But it’s not implemented as push-button ‘wizard’ approach. Instead you need to construct the necessary export template(s) that use your desired Markdown‡ flavour.
This begs the question, are you trying to:
understand the process and make your own templates?
asking for a pre-made example you can use (because you don’t want to learn/understand the process)?
I ask as depending on which bullet above is correct you need a different answer.
Tinderbox’s paradigm is to leave the user in control. IOW, you decide what you want to export and how. the defaults are either RTF text (for the ‘code’ averse) or HTML. But the template system is very flexible and you can generate a host of formats using the methods that make the (default) HTML. Tinderbox’s own Markdown integration presumes you are using Markdown internally, i.e. in note $Text, and generating HTML files. But, it is perfectly possible—as some users already do—to export text files holding Markdown-formatted text only, i.e. not post-processed into '.html. files.
†. A case in point, the original OPML standard was for [plain-text outline where—in terms of Tinderbox and other outliners—item title and text are the same thing. There is also no notion of, or support for, formatted (e.g. RTF) text other than view embedded HTML which in turn means some gymnastics in how data is encoded for the OPML. Note: OPML is written in XML.
‡. Note that, “Markdown is a lightweight markup language for creating formatted text using a plain-text editor”. That ‘formatting’ was HTML and IIRC the impetus was being able to write quick blog posts/press releases on a phone for HTML output. People new to Markdown thus assume it is a ‘standard’ (that word again) rather than an affordance for generating HTML (which actually is a standard)…
Now, this example is REALLY SIMPLE. I have templates that I’ve developed that will create an extremely nuanced markdown export with automated not numbers, quotes, images, heading formatting etc. I’ve yet to find really any limits.
FWIW, there is any interchange standard for marked-up, styled text that is a proper standard. Tinderbox has supported it for twenty years. It’sl HTML>
Adapting Tinderbox’s HTML export to various flavors of markdown is usually straightforward. For example, instead of <b>, you embolden a passage with ** and instead of <I> you italicize with `__``. Links might need some post-processing, depending on how you use them and what the consumer of the markdown files expects.
Here is another example. Creates a Markdown file from multiple notes. If you apply the Stamp “Create Draft” to one of the notes in the Note 2 tree Tinderbox will consolidate all the Markdown to a single note in “Draft” so that it can be exported as a single note. When you create the draft, Tinderbox will tell you you did a good job.
Also note, I have some action code in the tPageMD template that dynamically sets the first note selected as heading 1. I have use booleans so that I can dynamically suppress a title, text, or children depending on what I’m trying to accomplish, i.e. $IsNoShowTitle, $IsNotShowText, $IsNoShowChild.
REMEMBER: It is important to respect that spaces when writing in markdown matters, A LOT!
There are a ton of nuances in this file that I don’t have time to explain. Let me know if you have any questions.
Ha! I’ve no downer on OPML, but as an (ex-)data plumber seamless inter-app data exchange takes hidden labour we often don’t see, given that user ‘standards’ are often illusory. I’ll admit I used to want the ‘just give me an export button’ approach until I learned the hard way about ‘standards’. So, hats off to all the small software shops who fix these glitches in the background so stuff ‘just’ works.