Is it possible to assign a prototype based on characteristics of the name of the note?
For instance if I have a note with the name “Note - Thoughts on Tinderbox”. How could I detect the first word and then assign the appropriate prototype for notes.
Similarly “Task - Use Tinderbox to research Tinderbox”. Detect ‘Task’ and assign the prototype for tasks.
As well as the ‘code’ to detect the first word I need help with the syntax since there will be a list of prototypes to choose from.
I’m wondering if this would be a compounded “if” conditional statement but I suspect that would get very long winded.
I think as v9.5 was presented at last w/e 's meet-up, I can mention this…
Actually, this is coming any day now in v9.5.0. If you type a name like “Use Tinderbox to research Tinderbox#Task” for a new note, Tinderbox will recognise the #-delimited part and if such a prototype doesn’t exist it will make it† and add it to /Prototypes in the doc. The new—or pre-existing—“Task” prototype will be applied as the new note’s prototype (i.e. the value of its $Prototype attribute).
For those who use the zip method of touch-typing links to new notes, the same syntax is accepted. Note that the desired prototype’s name is #-appendedafter the note title (i.e. what becomes $Name).
The syntax will be further described in aTbref 9.5 when Tinderbox v9.5.0 releases.
†. In a case like ‘Task’ where there is a built-in prototype of that name that will be used added. IOW, the chain is: detect a prototype name ▸ is it in the doc? ▸ Yes—apply it as $Prototype ▸ No, but it is available from unused built-in prototypes—add it and apply it as $Prototype ▸ No, and not available from unused built-in prototypes—add a new prototype and apply it as $Prototype. In the latter case, if the doc has no /Prototypes container, that will be added and then the new prototype be placed in it.
Soon - as soon as the beta testers stop breaking it. (disclaimer: I’m one of them). Frustratingly for all the significant improvements in previewing and image handling that folk have (obliquely) asked for have collided with increasing macOS security restrictions to create a tough circle to square for the developer. In part we have to recognise that the suggested way of showing HTML (webpage) internal content that uses files outside the app can allow for badness if not handled with care. We rush to say, “I’ll never have that problem” but the design is now forced to allow for it.
So, a lot of unseen work going on to avoid surprises on public release.
If you want to go the agent route (there’s never just one way!) and wanted to lose the 'Note - " hint from the begining of the note $Name, we can tweak the Action a bit:
What’s the last bit? Well we wisg to dump the "Note - " prefix which is 8 characters long. The String.substr() operator. If given just one argument (input) number N, the operator returns the source string but starting N characters in. The N is zero based to the eighth place is 7 and thus the code.
But as noted above the new built-in method is a zero configuration method - it even makes the prototype for you, puts it in the right place and assigns it to the new note for the effort of adding a # marker in the initial naming. Still, it’s always nice to have choice.
Love this feature! Would it be possible to make the “#” and “@” toggle on/off option separate? Looking through forum posts make me believe that there are some people like me using “@” as a prefix for reference citekeys, but I would love to be still able to use the “#” prefix. I know there is an ‘agent way’, but I don’t want to make dozens of agents if there is a chance to have a simpler/memory-efficient way out.
I’m not sure that citation keys are all that common in note titles, as they tend to be long and unsightly.
The exception I can see right off the bat is that the whole title might be a citation key. This ought to be OK: we have some special casing (perhaps still limited to backstage builds) that says, “@(Whitt, JACS, 2016)” is unlikely to be a request to make an nameless note associated with the place (Whitt…).
To clarify for other readers here, parentheses and forward slashes in $Name are not a problem for general Tinderbox use. The problem being alluded to is where our TBX is using action code to (un)set links. It is in that limited context where those characters will cause issues (see https://www.acrobatfaq.com/atbref95/index/Automating_Tinderbox/Coding/Action_Code/Problematic_Characters_for_Action_code_in_Name_and_Path.html). Then again, for those users doing a lot of link based work or doing actions involving lists of paths (collect(), find(), etc.), it’s a constant concern. For them it is simpler to either (a) avoid using such characters in $Name values or (b) use $ID (or $IDString) in code where one would otherwise use $Path or $Name and use note names as make sense to the eye.
For learners, using $Name or $Path in code can be much more helpful to understanding how things work. For large scale use involving linking, $ID (or the newer $IDString equivalent) make sense. There-is-no-one-size fits all rule.
That’s good advice in general, but people don’t need to stress out on this. If your reference notes look like @(Witt 2016) , that might someday cause troubles with some kinds of automation. But for lots of people, the possibility that something might generate an error someday if you do something elaborate is really a lot less important than the things we know we want to do tomorrow.
Here’s this morning’s map view. It’s an effort to find a better way to organize a paper I’m toying with. It might end up being the core of a big two-year project, but it might just be a sketch for a little lecture or two. I’m thinking about sourcing and locating references (where did I put that Louis Sullivan book, anyway?) and writing stuff down.
If I need to automate something and need to revise a lot of titles, well, Tinderbox has lots of tools for that!
Totally agree; any issue only comes up with automation. I can also work around this by doing short-term transformations with action code. So it really is not an issue…really just more muscle memory than not.
(disclaimer: I’m one of them). Frustratingly for all the significant improvements in previewing and image handling that folk have (obliquely) asked for have collided with increasing macOS security restrictions to create a tough circle to square for the developer. In part we have to recognise that the suggested way of showing HTML (webpage) internal content that uses files outside the app can allow for badness if not handled with care. We rush to say, “I’ll never have that problem” but the design is now forced to allow for it.
