Since you are formatting the export in what appears to be wiki-links, could you share what you want the exported file to be used for? Ingested by some other application?
Export can be used to produce just about any plain text file, not merely HTML. For example, look at some of the OPML examples folks have posted here.
You can set the $HTMLExportExtension, which defaults to .html to be any other extension. Or you can change it in the HTML Inspector. Tinderbox has roots in HTML export, but that’s just history, not a limitation.
Could you post an example file to help the other readers here understand the context? E.g., is the note “My second note” the note that is being exported, or something else?
FWIW, ^outboundBasicLinks(,,,,)^ should export without the HTML markup.
Yes, export is an old part of the app (Tinderbox dates from c.2001) when blogging was still a thing, and some way before todays unicode-capable RTF. That’s the why.
I see another reply inbound—I’ll read that before continuing, but I do think the above contextual point is useful to bear in mind.
The big goal I’m working toward is to be able to export my tinderbox file to markdown files. I want to have access to them in markdown compatible apps for the iPhone and iPad. I’m reviewing the following threads:
I’ve added 2 new String attributes, $MyInString and $MyOutString. These are added to prototype ‘pNote’ KAs for testing purposes. In actual use they could be removed from the KA.
The building blocks are links(), a numerical sort .nsort (assumes all $Names are numerical values (already set from $ID), then using list.format() to create a string which is saved for use in the template.
I did try doing the above on-the-fly within the template using ^action()^ but it fails because the in/out links to the processed note can’t (I think) be resolved in that context. The .nsort simply ensures the notes list in consistent order (as links()may not always generate the link list in the same order).
This is a bit of a kludge approach as we’re simply doing something hitherto not asked for. IOW, perhaps a more efficient method can be found without each not needing to store (and occasionally re-compute) it’s in/out links. I’ve assumed no aliases are in the loop - but don’t overlook that assumption as you built out your file. I’ve no idea how this file performs at scale - that for someone with the need to test.
@mwra, it works beautifully! Thank you so much for you time in putting this together. I never would’ve been able to figure it out without your help.
I am excited and I need to weigh the pros and cons of this approach.
Pros
This is an elegant way to capture the incoming and outgoing links of a note. It really speeds up the linking process. I’ve just tested it and it works great in a few different apps for the iPhone and iPad.
Cons
All of the files need to be exported to the same folder. This means that if something is in a container or in a different container the links will break.
Aliases don’t work.
Is this something I should write up as a potential feature request or am I way outside of the box?
Tinderbox’s export has always worked off the document outline. I’d ease up for a moment: might it be easier to simply post-process the files exported from Tinderbox, and fix the links that way? As these appear to be plain text, it ought to be possible. Or use AppleScript for export , etc. There are other routes.
Asking for export that changes the source outline to something different, e.g. one single set of files, is something that might require more significant engineering. The ROI might not make sense given the other possibilities at hand. Remember, making a form of zettelkasten is only one of many uses, and over-optimising for one task may affect others, something to bear in mind when making a significant feature request. I’m not suggesting not doing so, but to do mindful of the wider app ecosystem.
It’s been a while since I’ve been tinkering with this, but here is the last file I had that I believe achieved a similar outcome to what you’re looking for. Let me know if you have questions about how it works.
Interesting! It took a while to figure the process but only in terms of where in the doc it happened. This is, with my file, is a nice example of two different implementations to the same end. Each TBX pre-compiles the [[ ]] delimited lists of in/out links as a user String-type attribute. I used an edict, @derekvan uses agents. Is there a ‘best’ way? I think not. In truth, once you’ve got a method that works, all the magic is behind-the-curtain and you likely won’t need to touch it again. So, it is really a matter of choosing a method you, the file’s user, understand as you will maintain the file over time.
Side note: if I were adopting this file as my own I would add the default /Templates container (by adding a built-in template) and move the templates—currently in /System/Export—into the ‘standard’ templates location†. I’d also re-import and re-link the ‘code’ prototype as I think that has also had some changes of late. That’s not critique of this TBX, which is pretty neat, but just as a way of keeping the under-pinnings fettled.
† This standardisation has occurred comparatively recently in Tinderbox’s existence. For long term users, there is no requirement to migrate to such norms. But given the constant evolution of the app, at some point these norms become assumptions for later improvements.
For instance you don’t want your templates becoming, by accident, a composite (composites and $NeverComposite) as quite recent in Tinderbox terms. The ‘HTML’ prototype (it used to be named ‘HTML template’) sets $NeverComposite to true. The built-in Templates folder (if added by the app) sets all new templates (i.e. created in or added to /Templates) to use the ‘HTML’ prototype and thus ensure they don’t composite accidentally.
