The new option to link to places by entering Notes as “activity@place” in TB9.5 is great. Thank you for including it. Maybe the following point is already in TbRef, but I mention the use I have found for this new feature to show how versatile it seems to be.
Rather than have a place as somewhere with latitude and longitude, I wanted place to mean a bibliographic reference. So I dropped in a few references from Bookends (which creates a Reference prototype), made sure all the references had easy names, such as “Smith1985”, deleted the “Place” prototype and renamed “Reference” prototype to “Place” and then applied it to all the references I had imported. After that, I am free to create notes on my reading, identifying the source by adding notes with headings in the form “Argument for monetarism@Friedman1968”. It works! OK, all the links that are created are labelled “place” when I would prefer “source” but I that is minor (and no doubt fixable).
This obviously gives me ideas for how the feature (I am not sure what to call it) could be extended. Could the prototype and link created when @ is used be user-definable, to avoid my deleting, renaming and reapplying prototypes? (Perhaps they are and I was in too much of a hurry to find out.) Or could @@, or some other symbol, be used to denote a different type of place, or different type of link? E.g. linking to same bibliographic references, but creating links labelled “quotation” and “content”.
Of course, I realise that the links I want could be created in other ways, but although all I have done so far is experiment to see what is possible, this way of creating links is so quick and easy that it has the potential to transform note-taking on what is being read, assuming it is always crucial to keep track of the source that everything comes from.
The idea is interesting, but given the observation about places being less useful than something else and the wide variation in how people use the app (a reference may be equally unuseful for some) it seems the value is the mechanism.
Therefore the mechanism might best be adapted by having some user-configurable options. For the latter I’d suggest in Doc Settings alongside the existing control for enabling/disabling parsing of (new) names for this purpose. As § (section marker) and ¶ (paragraph marker) are unlikely to be used in actual note titles, i.e. $Name value, and are easily typeable† these seem a reasonable starting place.
Even if @ remains mapped to places, these alternatives perhaps could be offered. A suggestion is that if these latter options have no value user-set the presence of the character in a $Name has no effect. Otherwise, the user supplied (case/spacing sensitive) prototype name is used (the prototype being added on first use if not already in the doc. Potentially @ could also be listed, preset to ‘Places’ but user editable to another prototype name if needed.
†.Of course, the description ‘easily typeable’ may vary depending on your locale, so we need to be accommodating . FWIW, on my en-gb Apple keyboard, the § is a normal key , to the left of 1, and & is Option+7 (⌥+7); Even in ‘English’ keypads there are differences as on an en-us keyboard the GB’s § is a back-tick and § likely requires a modifier key. It may be that the characters useable in this role may be limited by the number of those easily typable across the most-used locales of Tinderbox users.
Yes, absolutely. I did not mean to suggest that places were less useful than anything else, but simply that the mechanism is very useful, because it seems to have the potential to simplify the creation of connected notes. Suggesting this seems consistent with the TB philosophy of allowing users to do different things.
Sorry if I implied otherwise! I was reflecting you observation from your hacked alternate to a generalised one. Were this to be adopted, I could see disparate groups of users using one or two such mappings, with different mappings per group.
Even if defaults are supplied, presuming a best case default is obvious, being able to set one’s own seems a valid customisation in this instance. In testing the current feature, the prototype mapping made instant sense (and likely is a useful global mapping) but ‘place’ had me wondering how many people would use it. Of course more customisation is more engineering/testing so the use-case/ROI question comes to the fore. I think here the ROI is that more users will use the feature (other than just for prototypes†).
†. It took me a while of using Tinderbox before I begun the see prototypes for the force-multiplier they are. Now I tend to add prototypes early and often!
If this idea extended to the ‘zip’ method for text link creation, then it might partially fix this issue as using the ‘zip’ method would enable setting the text link’s link type at time of creation.