Further fixes to my Zettelkasten-like numbering code, including a user-configurable number of segment padding numbers. Assumptions as before:
- All zettel notes are descended from one container per document. If you need two discrete sets either use two TBXs. This method can only support a single note hierarchy per document.
- That container is at root level, though I’ve added a feature to let the root $OutlineDepth be below root.
- That container is not a zettel note.
Plus:
- Root zettelkasten note container is called
Zettels, case-sensitive
- Add a String-type user attribute,
MyStringA
- Add a List-type user attribute,
MyListA
- Add a String-type user attribute,
ZettelCode
- Add a Number-type user attribute,
ZettelPadNumber, default value: 3
- Add a Number-type user attribute,
ZettelRootNumber, default value: 1
- Set $ZettelPadNumber and $ZettelRootNumber as Key Attributes for container ‘Zettels’
The ‘My-’ prefixed attributes are used in the code and named so as to not accidentally affect Sandbox group attributes with the same name stem.
In the previous example padding was hard coded to 3 giving codes like 001.004.002. Now setting a value of 2 gives codes like 01.04.02 . The variable padding number is now set in $ZettelPadNumber in the ‘Zettels’ container. Note: the sensible range for $ZettelPadNumber is minimum 2 and up to c.4: a value of 4 allows up to 999 sibling zettel notes per containers but obviously makes for longer codes. The Value can be changed and will be applied the next time the code is run.
N.B. If you set, for example, a pad value of 2 and some containers actually have >99 notes the code still works but different segments have different numbers of digits. This will effect correct sorting using lexical sort, so set the pad value according to the maximum number of siblings-per-container you have (or foresee using soon). My hunch is most people will start on 2 and move to 3. If a need to set 4 approaches, you might want just break a current set of siblings into 2 containers (Tinderbox doesn’t really care).
The code assumes the container holding the steels is at the document root level, but pre-empting a another change, I’ve parameterised this. So, if your main container holding zettel notes is at $OutlineDepth of 2 set $ZettelRootNumber to 2. Simple!
Set this code as the rule in the prototype(s) used for zettel notes (or add to existing rule code):
$MyStringA=;
var vPad($ZettelPadNumber(/Zettels));
var vRoot($ZettelRootNumber(/Zettels));
$MyListA=collect(ancestors,$Path).sort($OutlineOrder);
$MyListA.each(X){
if($OutlineDepth(X)>vRoot){
if($MyStringA){
$MyStringA=$MyStringA+"."+$SiblingOrder(X).format(0,vPad,"0");
}else{
$MyStringA=$SiblingOrder(X).format(0,vPad,"0");
};
};
};
if($OutlineDepth>vRoot){
if($MyStringA){
$MyStringA=$MyStringA+"."+$SiblingOrder.format(0,vPad,"0");
}else{
$MyStringA=$SiblingOrder.format(0,vPad,"0");
};
};
$ZettelCode=$MyStringA;
Sorry, this took much longer than I’d imagined (checking edge cases, parameterisation of options, etc.), but here is a simple demo/test file: zettelcode-demo.tbx (115.7 KB)
I would be very interested to know if the logic of the ‘zettelcode’ mechanism is essentially feature complete. IOW, before building anything deeper off this I want to make sure we’ve not missed any obvious error or needed additional option.
I’m not wildly keen to do this as a rule, but for now it’s the best option. Discussion (elsewhere) is considering ‘featurising’ this as a an action or calculated attribute, thus the necessity to ‘freeze’ the design logic - or we’ll be at this forever. 
So, input on this is requested!
If you want to ask about action code logic in the code above, I suggest you start a new thread and link to this one so we don’t get thread drift.
