Hello all. I am marking some notes as a priority (flag yellow) and urgent (flag red) and using an agent to group them for me. However I would like to know the original location of the note and not the alias when I look into the agent container. Can I set or make an attribute that does something like $Path(Original) so it always shows the original and not the alias? Thanks in advance.
Youāre almost there: you want
$Path(original)
with a lower-case āoā. (All designators are lower-case: this, parent, previousSibling, nextSibling, etc.)
Further to the previous answer, see descriptions of designators, of which item-scoped ones are likely mrst of use here.
Thanks. I am trying to make this an attribute to be displayed but it seems to just display the code - $Path(original) - how can I get it to display the actual path of the note? Thanks again.
Can you please show the code you are using to set this value and say where (Inspector, Get Info, Displayed Attributes, etc.) you are setting it.?
My understanding is that you want every (or all relevant notes) to store their originalās $Path in a non-intrinsic attribute ($Path is intrinsic). So Iād make a String-type attribute āOriginalPathā and add it to the noteās Displayed Attributes. Then iād add an edict (you donāt want this running all the time):
if($IsAlias==false){$OriginalPath=$Path);};
The āifā is because aliases also execute the same rule & edict code as their original, and we only want this to run in non-alias (i.e. original) notes.
Thanks for all the help and pointers! I was just wanting to set all notes to display the path attribute by default (using DisplayedAttributes) AND also wanted the Path attribute to display the absolute path and not the alias always --> like $Path(original).
Great. Have the answers above solved the issue?
There is no āabsolute pathā in the way you describe it. The $Path for the alias is it absolute path. It is worth reading up on intrinsic attributes. The alias has to have its own path as it resides in a different part of the application.
What you access via $Path(original)
is better described (for fellow users here) as the āoriginalās pathā (āoriginalās $Pathā). The latter follows the shorthand convention here of indicating a textual reference to an attribute nameāas opposed to literal use of that word/titleāoutside code samples by using a $Prefix.
Thanks Mark for the clarification and help. I will review what you posted earlier, in-depth about intrinsic attributes.
Thanks. By all means post again if stuck. Intrinsic attributes and designators can seem a bit alien at first sight, but they are pretty simple.
This is a list of known intrinsic system attributes (as indicated by the XML source of TBX documents). Quite why $Path isnāt there listed Iām not sure but will follow up directly with Eastgate, as it behaves in an intrisic manner.
Adding to this thread, is there an easy way to delete an original from alias results? I realize that you can go to the original by rt mouse-clicking, but this takes steps. I donātā see a menu item for this and canāt figure out how to do this with a stamp.
OK, first a WARNING. delete()
is something to test before using in a working doc and keep back-up: this feature has no āundoā.
You could use delete():
delete($Path(original));
N.B. Iāve not tried it (late here) but it should work. Iād not automate it, but if the code works it might work well as a stamp.
Hello Mark thanks again. Writing it this way seems to have worked for me: if($IsAlias==false){$OriginalPath=$Path};if($IsAlias==true){$OriginalPath=$Path(original)}
I also put this as default under edict attribute (Document Inspector>General) so it covers everything inside the tinderbox doc/file. Is this the proper place to put it if I want it to be global or should I put this somewhere else?
Iām glad that works. It can be written more simply as:
if($IsAlias==false){$OriginalPath=$Path}else{$OriginalPath=$Path(original)}
Note that $OriginalPath is not intrinsic so only needs setting once from either an alias or the original.
BTW, Scott, would you mind providing some detail around the purpose of this need. What benefit will knowing this give you? Iām trying to get insight for one of my next videos.
Sure no problem. I have 3 agents running at the doc root called āUrgentā, āPriorityā, and āThinking about.ā That allows a top level view of any pressing issues I have (or my thoughts or concerns that are pressing). But I also have a hierarchy of nested containers and notes. When a note is urgent but is nested within a hierarchy for example and I want it front and center: I give it a badge āflag redā and the agent āUrgentā search for it and pulls it ($Badge=="flag red";
).
So this edict that runs on every note if($IsAlias==false){$OriginalPath=$Path};if($IsAlias==true){$OriginalPath=$Path(original)}
then labels the notes with their original paths so when I look into the agents on the top level (āUrgentā ,āPriorityā, āThinking aboutā) they give me their original location path of the note which in turn lets me know the context/subject matter it is related to therefore providing meaning - I could not get this from using the aliasās path. Hope this helps.
Sorry also I turn the (user attribute) āOriginalPathā attribute on in DisplayedAttributes so it shows up in every note.
The interesting meta-reflection for me, reading the last is we differ in our mental approach. My own immediate reaction reading this is āwhy would you not know where the original isā but Iām reminded we conceptualise in different ways.
That said, I have to ask what this means
What does the original tell you that the alias doesnāt? context: start from the assumption we donāt know know the view type of container-scope if the view you have in mind.
As most attributes are non-intrinsic, what does the differing context supply.
I ask as I sense you may be solving the āwrongā problem with this approach. IOW, there may be an easier solution if we understood the real underlying question.
I had the same reaction. To Markās point RE different approaches on conceptualization, here is my immediate thoughts.
You appear to be looking for context from the outline structure. If the note were to move, does this change the context of the note, or would this action simply put the not in a different container while retaining its context?
If the later, then driving context from the outline could be dangerous if notes actually move.
For a note to retain context you could create various attributes that retain the context. For example, I always apply a $Type attribute to every note, that way I know what kind of note the note is, person, event, theory, article, etc. That way, if I accidentally break or delete a prototype, Person for example, I can simply run an agent on all notes with $Type=āPersonā and reapply or apply a new prototype. So, $Type is an important context form me.
You could do something similar with other attributes, e.g. $Theme, $Category, $Effort, etc. Youād effectively be moving your context from outline position to attributes. In my thinking, this creates a lot more flexibility and mobility for your notes. It will allow for transformations as well as the ability to migrate notes between Tinderbox files, without losing context.
Hello Mark, hopefully these pictures will help explain some of this. I wanted a common area for my urgent and pressing stuff but without changing location of the note (location of the note as meaning for me). So for example I could look into the Priority agent and see what needs attention. And then I could look at the OriginalPath attribute and it tells me it original location. This is a simple example, some of my notes are more nested than this and that OriginalPath becomes more helpful. NOTE: I purchased Tinderbox 10days ago and been using it for 2wks so I am āin process,ā but reading the manuals which have been helpful. Thanks for all the input and advice.
Hello Michael, thanks for your input and pointers. Also I viewed most of your YouTube videos about Tinderbox and it was very helpful. Please see my reply to Markās post it has pics and an explanation about why I set it up this way.
Your Attribute vs location makes a lot of sense - I will need to think about structure and design. I just started using Tinderbox and its flexibility is still surprising to me (all the possibilities). Thanks again for the help.
Thanks. That makes sense in context. Given your approach of location within the outline having meaning (which is perfectly valid!) sing a noteās location from the aliasā Displayed Attributes makes much sense.
Your if/else approach of setting the stored path from both original and alias via edict should be pretty robust to the original moving. Plus, in the latter case youāve only to run the edict on demand from the Action Inspector, Edict tab to ensure all is updated. Or, by using File menu āUpdate Now, all Edicts are run once.