I’ve now had a chance to download the demo and test it, while reading the instructions in @mwra’s post above.
This code is numbering things exactly as I would expect it to. And the two variables that the user can set make it very configurable indeed.
For my purposes, this does what I had originally been looking to do. I’m trying to study the code with the TBX Reference open alongside. Also, I’ve only tried it in the dummy file. I’ll try to implement it in (a copy of) my working document to kick the tires a bit more, and get back to you.
Thank you very much, @mwra.
Ooh - hit top dead centre for once. Good news! I hope the demo helps others. A method to implement a ‘numbering’ system something like this in Tinderbox has been suggested and is being investigated (though I don’t read that as necessarily getting carried forward.
That said if others here have comments/requests on the narrow issue of zettelkasten-like ‘numbering’ do please say so.
Meanwhile, I’ll follow up with @talazem on the export side of his original request (we’re on a PM at present) and I’ll share back a further demo if we make sensible progress.
If you make “sensible progress” I’d love to see the demo! I was getting hung up in all of the details of making the perfect export and numbering, etc. I’ve taken a break from it and I’m focusing on reading and taking notes! I will want to circle back at some point to tweak it for export, etc.
Sure, that’s the plan. I’m pushing ahead on a PM queue as we’re gently pulling out edge case stuff and it might sound like crickets here but progress is happening. for instance @talazem noted that using full stops (periods) for the segment delimiters in the code fails if you use thr code as the zettel note $Name. Why? Consider, if I export ‘001.002.003’ to HTML, I end up with a filename ‘001.002.003.html’. Not helpful!
So I’ve also parameterised the the ‘code’ segment delimiter in the ‘Zettels’ note. a full stop might work well internally, but if exporting you might want to use a different delimiter. If you don’t, a full stop might be more useful in giving horizontal compression of a long code.
So here is an updated demo. I’ve changed $ZettelCode to $ZettelNumber to ttack @talazem’s ussage but nomne of these user attribute names are writ in stone. Change them to your needs - though make sure the code-setting rule is updated.
zettelcode-demo.tbx (115.8 KB)
Thanks, Mark! I wasn’t trying to push. . . I’m just really curious to see demo files of Zettelkastens.
FWIW, I’m using a fixed reference named $Zettel_String. I use this as an Action:
Interesting. I’m a bit of a by-stander here, as in I’m not a zettelkasten-er (I know, not on trend at all).
I get what code you get but I assume it doesn’t allow for subsequent zettel-note moves in the TBX?
Correct. I want my Zettels to have a fixed ID. If I ever dump notes into a markdown system such as The Archive I would want the numbers to be consistent. I want to be able to move notes around in a hierarchy and still retain my IDs.
Err, but they do: $ID (Tinderbox’s UUID for notes). See here. Or am I misunderstanding?
Sorry, I don’t mean to get the conversation off track. I like having the ID built from the date., i.e. 202003251154. I’m drinking the kool-aid over here: https://zettelkasten.de/posts/add-identity/
Nothing wrong with that! I’d simply mis-understood your earlier comment to imply Tinderbox notes had no unique ID. Date/time of creation is an alternative. Although date/time attributes reflect time to the millisecond, depending on how you
format the data not all note will have a different value.
Even if you use some other $Name, you can still sort on $Created—or any other date.
I can’t help but reflect that Luhmann’s system was constrained by the limitations of the (paper) card medium. Recreating that in a tool as rich as Tinderbox can be fool’s errand if recreating limits dependent on the paper medium. That’s not critique. If a solution works for you, that’s good.