There are a number of useful search functions in TB e.g. find() and others which require the user to identify the attribute to be searched within in each note. At the same time there is a global find function in the menus to search all notes for a specific piece of text.
My question is whether a function exists to search in a similar way to the global cmd+f function which would allow agents to search through all notes without knowing a priori in which attribute the text needs to be found ? I havenât seen it yet.
Thanks - I thought so but wanted to be sure. In my case when starting with TB three or four weeks ago I created many notes changing the attribute names to store the same information type fairly frequently. This was my TB discovery phase. This means I have notes with say the text âSoil Moistureâ connected to user attributes such as $MyText, $Product, $Application etcâŚIâm cleaning up now assigning all notes with information on soil moisture the attribute $SatelliteProduct == âSoil Moistureâ.
Iâm using the global find provided by the TB environment. I only have 40-5o notes and perhaps 5 attributes to clean-up into one so the manual clean-up is ok. For several 1000s it would be more onerous.
Perhaps at a tangent, but a good strategy is to put things you want to search for in a discrete attribute. If you need clear sub-groups within your overall âtagsâ (keywords), use discrete attributes.
I find Tinderboxâs built-in search leaves a lot to be desired, but you can improve things by using an agent.
This TBX file (57.8 KB) has a top-level agent that will search for notes that contain all of the words in its $Name. (Note that unlike in the built-in search, the words can appear in any order and need not be next to one another, or even in the same attribute.) You can specify which attributes the agent searches by setting the agentâs SearchAttributes key attribute. This search is potentially quite costly, since it will be common to search through the $Text of notes, so if the agent has no words in its name, it deactivates itself, and reactivates itself when a word is entered into its name.
I usually have one of these at the root level of my documents ready to go if the built-in search doesnât get the job done.
This still doesnât do what youâre really looking for, in terms of searching every attribute. But itâs easy to add a large set of attributes to search, which is not possible in the built-in search.
A brilliant answer from Galen - many thanks. Iâm using the occasion to learn a little more about actions in TB. I understood the edict (which switches the agent on and off depending if there is a name or not). The code for the actual search is a little more mysterious.
the left hand side is a concatenated string with the attribute values in each note to be searched, correct ? I assume that $MyRegex(agent) is then a list of search terms but Iâm not sure what it looks like in practice. Can you give an example or explain a little more the mechanics ?
Thanks - in fact there are some useful TB idioms in youâre answer. In particular the distinction between attributes that carry information ($MyRegex as an example) for the computation and attributes that execute code ($AgentQuery).
In this case the answer I was looking for is plainly visible under $MyRegex.
Yes. In the context of the query, $SearchAttributes(agent) refers to the agentâs $SearchAttributes attribute (set to the string "$Name + $Text + $MyString" in the example document). When this string is evaled, it is evaluated in the context of the note the agent is examining, so the $Name, $Text, and $MyString of the note the agent is examining are concatenated together. This is then searched to see if it matches $MyRegex(agent).
$MyRegex is set by the agentâs $Edict. The edict uses the string .replace operator to put each word in the agentâs $Name into a non-consuming-match expression. (In the example document, the agentâs name of âfoo barâ yields the $MyRegex(?=.*foo)(?=.*bar). Briefly this regular expression looks for âfooâ anywhere in a string without consuming any of the string. It then looks for âbarâ anywhere in the string without consuming any of the string.) The result is a regular expression that will match when every word present in $Name is present in the search string.
I feel if I can teach myself how this works, the scales will fall from my eyes and my use fo Tinderbox will become MUCH richer⌠But at present I donât quite understand how I would construct something like this in my own document. Am trying!
The original question was, "can I search for âPlessyâ anywhere? Tinderbox doesnât do this because that would be slow: a Tinderbox note has something like 500 attributes. Itâs not very likely that Plessy would be found in $BorderColor or $Phone, but itâs not impossible.. And then, when you find that thereâs a âPlessyâ in some attribute of a note named âJames Arbuthnotâ, how would you figure out in which attribute it was found?
If you could tell us a bit more about what youâre working on, I bet we could find some helpful ideas!
If you are looking for a word I agree that you probably have an idea in which attribute it might be located. The problem I face sometimes is when I export and then re-import a spreadsheet into TB. Perhaps I changed a couple lines in the sheet which are now notes in TB but can remember which ones.
Ideally I would like to locate those notes which are identical to each other and eliminate the duplicates. Identical in this case means the same attributes (including text). There is no way to my knowledge of asking TB whether this note is identical to the other. Only on an attribute but attribute basis.
I share the the same mystification. âGarbage-in-garbage outâ or âwhereâs the piece of paper?â. This is why process-led things like Roam, or zettelkasten confuse me. Tipping all my cr*p, into the hopper of a fixed process doesnât, of itself, really help with making sense of it. Also, it seems natural that the app should just know, but as has been noted above that means many places we likely donât want/need to look.
Unless I embrace metadata likely all my âwordsâ are marooned in $Text or $Name which are easy to find. If I use âtagsâ (aka keywords), $Tags might be of note. Beyond that the âwordsâ are in a user attribute to which I ascribed it.
The point being, I think the premise here is flawed. At loosest I might want to search every one of a list of user set attributesâ for a value. But this begs the question, if I donât know where I put the data in the first place, should I not solve this upstream.
This isnât critique but a reminder of enlightened self-interest. IME, with Tinderbox, the sooner i place critical words or group-labels, into user attributes, the more useful the app becomes. Every time, in my own work, I find myself testing $Name/$Text, I think Iâve failed. Metadata FTW!
On the other hand, I can imagine wanting to have a query that asked:
⢠Are the user attributes for these two notes identical?
⢠Are the Displayed Attributes for these two notes identical?
⢠Given a list of attributes, are the attributes on that list identical?
Hits the nail on the head. For instance if the user attributes for one of the notes is not identical to the other one then it might be a good idea to make them identical in some cases or perhaps they are duplicates and the $Text elements should be merged. I have notes in a container sometimes which - since they below to the same project, are written by the same person etc⌠will often (not aways or Iâd use a rule) should have the same user attributes. Writing them down quickly e.g. during a meeting I donât always have the time to fill out all relevant attributes. I can quickly adjust later it if I have a mechanism to check the equality of a note with say a reference note with all field filled out properly.
I donât have a real plan for this yet, but I need practical projects to understand how stuff works.
Practically speaking, I would only likely be searching $text and $name, as suggested above. I think it would be useful to have search agents that can look for thinks like:
Names, when I inconsistently spell them (Christopher Hatty v. Christopher R. Hatty)
Words I frequently misspell by transposing characters (reciept/receipt)
Maybe impossible, or may already exist, but Iâd learn from trying!
Tinderbox attribute names are case-sensitive ($Name and $Text). Without wishing to appear pedantic, Iâm aware we are all used to different conventions so what might be casual typic might easily be an echo of conventions in some other app.
I use TextExpander. Iâm a left-handed, dyslexic, two-finger typist. Iâve stopped worrying and just add my commonest typing errors to TextExpander and my cr*p typing is (mostly ) hidden from the world.
Detect these errors is best done in input, AI cleverness is unimpressive. Apple apps constantly flag there, theyâre as potential errors when they areâto any literate English native speakerâcorrect. Computers canât yet truly understand the range of human writing.
) hidden from the world.