Am I the last to find this out or is this a genuine discovery?
I just stumbled on something wild: if you type a # followed by text in the $Name of a note, Tinderbox will automatically create a new prototype using that text as the prototype’s name. The prototype is placed in the default /Prototypescontainer.
For example, if you name a note I hate #books, Tinderbox creates a new prototype called books, moves it to /Prototypes, and truncates the original note name to I hate.
I didn’t see this documented anywhere, even in the almighty aTbRef. Is this an official feature or a side-effect of something else?
Given the accidental nature of the discovery, and whilst the feature is covered in aTbRef (thanks @archurhh), is there somewhere you expected to find the issue covered but found nothing?
For instance, my article on Attribute Naming predates the above but really ought to warn that use of # and @ in $Name are —in default settings state—potentially problematic. I’ve made a note to self to amend the latter article.
[Edit: er, No—not attribute names, but note names yet the same need for clarification applies.]
Obviously one can’t link everything everywhere, nor seed for every ‘how’/‘why’ question. Perhaps a good place to start is aTbref’s search page, and citing search strings that don’t find a match. Rather than address every mismatch I might still usefully be assisted to spot ‘entry points’ to the corpus that aren’t well covered. Whilst the app has terminology of its own and which I think is covered, I can’t account for how individual style in phrasing searches: frustratingly, we all tend to do things a little differently.
FWIW, I was a bit sceptical of the new-ish (aTbRef v9.x?) ‘fuzzy’ search feature but I now use it quite often—I use the website more often than the TBX as I’ve other large TBXs open. The results are surprisingly good - the ‘fuzzy’ search dealing with some of the issue above of finding the right issue. If I search for ‘# in name’ match #1 is Recognize #Prototypes and @Places in Note Names. Sweet!
Crikey! How embarrassing. I ran through all your pages on prototypes and then scanned the mega-prototypes page (this one) and then felt justified in calling it a day.
And there it was, in Document Settings, all along!
Don’t feel bad, things are so often only obvious after the fact. A takeaway—for me at least‚ is to encourage more use of aTbRef search, now it has been around long enough to show it is useful. I’m minded to remove the Google/DuckDuckGo searches as TBH I don’t think they ever worked in the way intended†.
I do use some Google tracking to look for possible gaps but even that doesn’t offer meaningful data. So perhaps might go too. As might the Google tTranslate as the little feedback is that despite good intent (of me and Google) technical writing doesn’t auto-translate well because translation look-ups tend to translate specific-to-context terminology literally with some confusion arising for the poor reader.
I should add that the app’s Command Bar‡ does use aTbRef as a source but I don’t know how dynamic the binding is. IOW, if wanting answers from aTbRef, the site’s Search (available on every page top/bottom) seems a better option.
Anyway, glad the original confusion is resolved. I’m sorry for some topic drift but questions like this thread are actually really useful for shaking the tree on un-tested assumptions in user-facing help.
†. Problems at the search engine end, and partly their lack of any human-useable feature documentation.
‡. For a small number of people a Command Bar is the main/only way to find things and unhappiness ensues when the listings come up short. As an app offering a Command Bar is a secondary feature, the awner there is to use primary Help resources as it’s hardly much effort to do so.
This originated in a very good demo in the then-new Tana, and it did seem compelling at the time. I’m not confident at this point that it was a good idea; it seems little-used.
@ also has a useful special meaning; “call Robin@work” makes a note named “Call Robin” and links that note to the Place named “work”, creating that place if needed.
I’m reminded, on digging deeper there actual isn’t any documentation at all on note naming (setting $Name). The issue is partly because I don’t think there is a limit though there are a number of things that are not good choices for non-trivial use of the app.
This article, Problematic Characters for Action code in $Name and $Path, is probably worth a read. The issue is less about what is value as a value of $Name than how that name is (in)correctly interpreted internally within the app.
Unawareness by an individual does not mean “little used”. Besides, how would Eastgate know what we use or don’t unless we say so. (Or, unless we’re monitored?)
Well, it’s not much discussed. No bug reports from edge cases fill my inbox. No paeans to the virtues of these shortcuts show up on Instagram, or if they do, I don’t know about them. The @ notation would leave traces in documents sent for support, and I haven’t noticed them.
More broadly, I really do try to listen to what gets people excited and what doesn’t. We don’t have performance monitors.
