Zettelkasten export?

Hi all,

I’m a bit rusty on my Tinderbox after some time focusing on iPad workflows. But I’m more and more interested in the Zettelkasten note-taking method, explored by some others on the forum. What I’m wondering is whether it would be possible to make a Tinderbox export template for exporting “conventional” markdown files with “Zettelkasten” formatted links? Let me explain in more detail below:

A conventional Zettelkasten file might look like this:

# Title of the note

tags: #tag1, #tag2

Text of the note. With a [link to an external site](http://google.com).

We might also have wiki links to other notes:

[[201901011200]] A note with a timestamp designation
[[201810101200]] A second note

This note might have the following file name: 201906051622 - title of the note.md

Let’s say I made a Tinderbox file with notes that had similar internal content: they had text and they had links to other notes (and these links are actual internal Tinderbox hyperlinks). Also there are “tags” in a set attribute.

Could I create an export template that turned Tinderbox hyperlinks into these wiki links? Using the note’s datestamp and the note title? I’m fairly certain it would be easy to add in the Tag attribute data as well. Assume that all these notes are in the same container and will be spit out to a single directory, so no envelope/letter messiness needed.

Assume also, I suppose, that all the links here are in-text links. We’re not talking about note-to-note links. Unless perhaps someone has an interesting idea about how those could be rendered to the Markdown file.

I’m happy to hack on this myself, but thought I’d reach out and see if someone else has managed to make something like this, or crashed unsuccessfully against the shoals. I’ve done a lot of interesting stuff with Tinderbox over the years, but actually rarely done much with links and never exported files with links.

Thanks!

2 Likes

So you want a link in $Text that looks like this to be exported so the link anchor text (the underlined blue bit) with code like [[201810101200]] where the contents of the wiki-link is the $ID of the Tinderbox link’s target note.

The latter feels do-able. Harder is retaining the anchor text we don’t have scripting access to that

Yes, I think this is what I’m looking for. I think the anchor text won’t matter so much because it will usually just be the timestamp number.

although, I don’t think I want the $ID of the Tinderbox link’s target note, I want its time stamp (YYYYMMDDHHMM).

Hmm, actually, the more I think about this, maybe the link itself doesn’t matter. As long as the export creates the file names as expected, and the user puts the correct digits in the text wrapped in brackets, the markdown files will work in other Zettelkasten software.

But I am interested in link export and what the possibilities are here re: turning links into markdown formatted or wiki formatted links.

Which one - $Created or $Modified? That said the problem is less that choice than elsewhere in the desired process.

OK, once we know what a links target is we can essentially get any attribute pertaining to it. However, what we can’t currently do is reach into $Text being exported and on-the-fly do a calculation on that. There is more hope of doing something with basic links (i.e. note to note).

Thus, for now I’d say your scenario isn’t possible without a change to the app, you’d need a way to—within processing of ^text^—to set a custom manner of processing text links and the output (code) generated. This sounds like a feature request needs to be raised if you want to see this.

ok, thanks for the input Mark! You remain an amazing resource here. I’ll take this up with Mark B further as I think more carefully and experiment a bit.

One more quick question: I reviewed atbref but didn’t quite understand. How can I create an export template that grabs a link in $Text? I see all the inbound/outbound links for note-to-note links, but how do you get attributes of in-text links? Happy to have a link to atbref rather than a lengthy explanation if that saves you time.

If I’m reading this page right, it’s only possible to get lists of in text links, rather than getting particular ones? So all in text links could be exported somehow at the end of a document? I feel like I’m missing something here. If Tinderbox is used to make a website, the in text links work just as expected, with the anchor text and the link and all that.

That’s the point - you can’t. You can query a note and see inbound/outbound links. that can be filtered further by direction and link type. However, action and export codes can’t fetch only basic or only text links. Nor, in the case of text links can we access the anchor text for those links. Furthermore, even if you figure out the desired timestamp string, there is no easy** way to to insert the time code in place of the existing text link anchor.

** I’m sure some baroque bit of post-processing or such could be done, but I assume you’re asking for a solution within TB and which doesn’t require general coding skills.

Like I say, I think this is a significant departure for the existing behaviour and something for which someone who wants it should make a feature request.

There’s no foul here, it simply happens that you’re asking for a behaviour not previously needed/asked for. At some point every idea is new.

Ok, got it. It’s funny, I tend to see Markdown files and HTML as essentially the same thing, so since Tinderbox spits out HTML so perfectly, I thought it would do Markdown the same way too. I see that’s a broad assumption.

I’m thinking that there are some ways to make this work by being more careful about how one writes the notes, but I’ll have to experiment a bit to see where I can get.

Thanks again for your help here!

I think the markdown/HTML difference is explained by Tinderbox’s longevity. Back in 2001, blogging was one of the use cases for the app but markdown didn’t appear until 2004 and even then probably took a good few years before it achieved any breadth of use. Tinderbox’s handling of markdown is comparatively recent addition and uses a form of post-processing, or at least alternate processing, via the markdown script in the app (or user-supplied alternate).

The problem boils down to where in the process you figure out the alternate target ‘url’ (here the $Created data/time) and how you you insert it into the process. Plus you want the link output to use wiki-style [[target_wiki_pagename]] mark-up.

If you make your zettelkasten notes use a $Created-derived date/time string as their name (with the text name as a $DisplayName then would solve part of the issue of getting the correct destination into the URL.

I’m not a regular user of markdown export, so my expertise is thin here, but perhaps a modified markdown script might work, or further post-processing markdown->html output.

Any markdown users out there with a more informed view on this?

Hi Derek, stepping back (this sounds interesting), what is the context of the export ?

(You will be working with the Zkstn records in TBX, and exporting for document production, or a web site ?)

1 Like

Hi Rob,

Good to see you on these forums! I’m guessing the new AppleScript support caught your attention.

basically, I’m looking for compatibility with a bunch of apps that expect wiki links (and typically wiki links with these date stamps). For example, see this app based on python, or this one based on nvAlt. Additionally, files with these wiki links are now supported by 1Writer on iOS (clicking the wiki link essentially drops you into search, which works well with these numeric date stamp names).

I’ve changed my mind enough times on tools for notes like this, that I try to plan in advance how I’m going to get the information out when I change my mind. The plain text markdown and wiki link format seems to me the most portable and long lasting, and easiest to transform to another format down the road if necessary.

1 Like

I’m thinking that this might best be supported by looking at the $HTMLMarkup value of the current export template. If true, we’d export text links as markdown instead of exporting them as <a…> tags.

1 Like

Some moderate success here. Documented in another thread.

1 Like