Starting point of what I have in my Tinderbox file:
I have a container Seedlings with notes, that I think are worth being worked on and visible. These outline order represents a ranking of how important the notes are to me.
I have a container Speculative Outline, where I want to sort notes from Seedlings, so that notes on related topics are grouped together, like one would using chapters, sections, subsections etc. in a non-fiction book.
What I wanted to do just now:
Move one of the notes from Seedlings to Speculative Outline.
What I did not like about what I could have done:
If I simply move it, I loose the information of where among the other Seedlings it ranked.
If I instead create an alias, I feel that when later visiting the Outline, I may miss out on descendant notes nested under the original note, as the alias will not carry these.
What I wondered about/wanted:
Is there a visual indication on aliases (in outline view especially), that tells me, it has child notes? If not, what would be a good way create one?
Why do I want this?
Ordering note-for-note gives me a better representation of what I want to work on.
Sure, I could say āsort all of them into categories, and then sort the categoriesā, but something is lost if I do that:
A small note, that I consider ālotās of benefit for few workā may rank high in terms of what I want to work on ā even though the overall topic is not the most important one. If I have the ordered list of notes, it will be at the top ā if I only have the sorted chapters & categories it may be overlooked.
PS:
This shares the same core as what I asked for in this thread here: Multiple map arrangements of the same set of notes , creating multiple arrangements from the same set of notes. In the end it comes down to me bumping into Tinderbox being designed with an architectural approach i.e. āa thing can only be in one placeā (correct me if I recalled this incorrectly). Keeping the āoriginalā notes in a large container without any structure as soon, as I want to use it in 2 places also seems appealing to me. Then Iād just have two aliases and the original in the āunsorted pile where all the things liveā. Always seemed to cumbersome though ā but may be possible to get working with action code etc. ā¦?
My first attempt at a solution would be to display the number of child notes as a column in the outline view ā but I donāt really like how it clutters the view with a lot of irrelevant information (for non-alias notes I would not need it as they have their children nested and I can always see the triangle indicating they are there).
One approach would be to have each of your seedling notes adopt a common prototype, perhaps A Seedling. Then, add a Badge to the seedlings that have child notes. You could automate this with a rule:
If youāre already using $Badge a couple of other, less optimal alternativesāwhich Iād still suggest applying via a prototypeā¦
#1. Flags. An outline item can show the notesās (first) flag (from $Flags) as described here: Flags in outlines. The downside is, that the selected item - the one youāre likely looking at uses the same space for the link widget thus:
Tip: As $ChildCount is a Number-type attribute, by default it displays 2 decimal places, i.e. ā4.00ā not ā4ā as makes more sense. tho get zero decimal places dipslayed in the pop-up where you select the attribute to display, change the value of the Decimals box from 2 to 0.
Why would you prefer the Badge over the flag with number? I think directly seeing the value of $ChildCount is very nice, so I assume there must be some downside you have in mind, that I am overlooking? Or is it just the fact, that it takes the spot of the Link arrow?
Yes. As stated/illustrated: when a note with a flag is selected the (outline view) space used to show the flag is replaced, for good reason by the link widget. But, if that doesnāt bother you, the flag is a nice alternative.
Note in the article on flag syntax that a flag can hold 1ā3 characters. In fact the limit is not the count of characters in the number but horizontal space. But hopefully youāve <1k child notes in your scenario.!
One could have guessed it: next issue I am facing is identifying all seedling notes that have no alias in the container speculative outline.
As Iāve read elsewhere on the forum, notes do not have a record of all their aliases. So there is no $AliasCount, and no easy way of querying for all aliases. Is this still true (thread I read this in is 5 years old)?
Ok ā so $Aliases was added at some point after this thread.
My quick and humble fix will be to indicate with a badge those seedlings that have no alias at all, and additionally show $Aliases via $DisplayedAttributes ā so I can see if those with aliases may still not have one in the speculative outline.
If I can carve out time, Iāll also try to get the actual logic I want, which would be a flag being set if
there is at least one alias of this note, in a specific container.
A thread from 2018. There is no resource mechanism for going back and annotating more recent app changes. Too big and unbounded a task.
Pertinent though is to ask where you looked in the app/help/documentation and didnāt find your problem answered. Indeed, what were your search terms? iām not asking by way of judgement but instead to see if thereās a gap in the docs. The apps open-ended, so there canāt be a canned answer for every processes, but the building blocks for those a (mostly) described. Yet, weāre always looking for oversights.
[quote=ārald, post:10, topic:7119ā]
If I can carve out time, Iāll also try to get the actual logic I want, which would be a flag being set if
there is at least one alias of this note, in a specific container.
[/quot]
Definitely do-able.
The joy of Tinderbox is you can do this. Sure, you set the logic (action code) but at least there is the choice.
The fact this count/logic isnāt baked in serves to remind us how personal are workflows are. The choice is to work in the walled garden of fixed system where you do what the am allows/demands in terms of process, or you trade that for rolling your own albeit at the effort of coding the necessary automation.
And the forums here for any questions if/when you get stuck.
Google query for āalias count OR many tinderboxā iirc. That brought up Aliases in aTbRef and 2 posts here on the forum. Forum posts indicated what I was looking for was not easily achievable 5 years ago. On aTbRef I did not see anything contradicting āthere is no attribute in which a note keeps track of itās aliasesā on the aTbRef page (there may be ā the page is quite long, so I quickly skimmed over).
In general Iād say I tend to look at the forum first, because I often find what I need easier (search engines work well on threads, where many different words are used for the same things ā if I miss the terms used in a concise reference doc, Iāll not find anything). Once I know more precisely what I need & what itās name is/may be, Iāll turn to aTbRef.
Well, now I tried. My idea was to use $Edict, which Iād set via a Seedling prototype.
First step was to just test my edict, so I just manually changed $Edict for one of my seedling notes, without using any prototypes:
if (find($Name==$Name(this) & $IsAlias==true & $Container=="/Speculative Outlines/tobenamed/").count>0)
{$Color="green"}
else
{$Color=;}
This worked as expected.
So now I tried to use this as for $Edict of my Seedling prototype.
But that leads to the prototype itself getting $Color=āgreenā (and inheriting this to any seedling, regardless of itās aliases and thus breaking what I wanted to accomplish) ā even though there is no alias of it in the container ā/Speculative Outlines/tobenamed/ā.
Could you explain why this happens?
Prototypes are notes like other notes, and may have rules and edicts that affect them.
Often, as here, you want a rule or edict on a prototype so instances will inherit, but do not want that rule or edict to apply to the prototype. The boolean attributes $RuleDisabled and $EdictDisabled do this. These are intrinsic attributes, so their values are not inherited.
You can set these attributes in the inspector (lower-left corner):
Thanks. This is helpful. as (disclaimer!0 I write aTbRef, I think I might be able to make things more findable. Some tips arising:
use Cmd+F (in-page find) in your browser on the aTbRef site map page (linked in the head/foot of every site page). Though it wouldnāt have helped in this case an in-page search might have found you the page for the $AliasCount and that page might have got you some way to your goal.
an oddity that isādepending on your taskāa blessing of impediment is the fact that whilst an agent query automatically de-dupes an favours an original a match, find(), operates differently. find() on a note $Name returns a list of all matches, i.e. original and all aliases. Filter that list for an ancestor note all matches need and it might help your general plan.
Anyway, thanks for that feedback, Iāve got some useful pointers from it.
I was not aware of the aTbRef Site Map page. I definitely have used other links from the Quicklinks section on top of each of each page. But never that one ā I did not get what was hiding behind the name. I would for sure have clicked on something like Searchable outline of all pages. If you want to improve discoverability of that page, maybe a rename or adding a hint in parentheses would be an idea.
Definitely my new go-to resource now, instead of Google.
Given the size of aTbRef, the sitemap isnāt particularly easy to read due to length. But, it doesāallied with in-page searchāoffer a quasi-index. An automated index for the site would be bigger (good indexing is still really a human skillāwhat to omit or elide). The sitemap at least gives something searchable.
The site map was also part experiment in using the envelope/letter (re-cursing) template technique. A challenge (unseen in the final output) is whether to list all agent contents (as the contents are all aliases)āthere is not ārightā answer.
An as yet unrealised experiment was to label some (all?) notes with extra metadata (essentially search-related keywords) to address the issue where a noteās title ($Name) omits words relating to its content. Bear in mind:
Tinderbox omits static sites. For a long-lived resource (aTbRef is 19 years old) moving/renaming notes has non-trivial effects. I flirted with fixed HTML names and letting titles change but it just made for an admin headache. As aTbRef is only me, in my spare (!) time, tit wasnāt a sustainable approachāthough it might be for other peopleās projects.
I try to name notes either for the feature they describe, e.g. āDocument Inspectorā, or the nature of the task, e.g. āStream Processing and parsingā. This often does not mesh well with the terms a questioner might use to search for the article.
In the early days, I flirted with a wiki-style approach but you end up with both weirdly named articles and in in-text anchors that jar.
Iād like to recognise a member of our community, the late Rosemary Simpson, who had expertise as an indexer. Over aTbRefās life she gave me useful advice as to how I might make things more findable within such an expansive work. In part it made me realise that a human-compiled index simply isnāt possible in a one-person work like this which is under constant expansion/re-factoring (i.e. possibleābut not with available resource).
So, the sitemap is the best of the less-good options! I hope this digression also explains why there isnāt a better index!
Prompted by @rald, Iāve added a section to the main page on Aliasesā see heading āFinding and counting aliasesāāand cross-referenced is to the article on the system attribute $Aliases.
Making that content more findable remains as a challenge, but at least the topic is now mentioned somewhere. The change to the āAliasesā page shows another challenge: Tinderbox lacks any automated way to insert anchors to headings in a page. It os part of the reason aTbRef has so many small pagesāaddressability.
Anyway, I hope that helps, even if after the fact.
One final remark, for possible future readers:
I initially wanted the aliases to form the speculative outline and the originals to remain in the seedlings container.
Quickly I realized, that putting together an outline using aliases is not a good idea: Aliases can not have children. So if one seedling would naturally be a child of another, I can not represent that in my outline.
Resolution:
Create an Alias for a seedling when you want to place it in the topic-based outline ā this alias can stay in the original location and the original note will live in the outline.
I explicitly want all the seedlings in a plain list without nesting in the Seedlings container. So it does not hurt that aliases donāt allow children for this list.
