Hey there, I’m late to the game but I thought I’d share the solution I came up with and the steps I took to get it working. I love the group or statements as suggested by @eastgate. Used that in my solution.
I took another approach and used a conditional edict. That way, when the conditions of no values are fixed the warning badge will automatically turn off (I have not developed the nested to turn the badge on to something you might want). I also documented the steps I took to understand what was going on and make sense of the date.
BTW, per my suggested solution, I’d not go with agents to do this work. It will put too much load on your file as the file gets bigger and more complex. As you incrementally think through what you want you can build an edict to accomplish this. You may need nested conditional statements, which you can manage writing in a code note.
I’m not sure I’d agree with @satikusala that using agents will put too much load on your file. This seems to me exactly what agents should do.
I see three situations when you might want to avoid agents, but they’re all fairly unusual.
You know in advance that your project is going to test the limits of Tinderbox, and your project cannot be split into separate documents.
The computation involved in choosing the colors requires Tinderbox to examine every note in order to choose the color of a single note.
You care a very great deal about battery usage; for example, you fly across the Pacific every week, and you cannot switch to manual agent updates.
This has changed a lot since early Tinderbox, when computers were slower and agents interrupted your work.
I’d say: use agents freely. If you start to see signs of a performance problem with agents, switch for a few days to manual agent updates and get in touch with us here or tinderbox@eastgate.com.
This is a really useful dialogue for me, @satikusala and @eastgate . Although I am inclined to use agents to start with, my Zettelkasten is intended to grow throughout my entire life and may perhaps reach a limit for smooth operation someday. Then, I have the edict solution to fall back on. Luckily, it seems like the developments of both computers and Tinderbox will continue to outpace the development of my Zettelkasten. Moore’s law or not Thanks to both of you for not only teaching me how to use Tinderbox, but also how to think Tinderbox.
Wise words, indeed! I will give it a go to reduce the number of agents already now, though. To practice, as well as to take heed of @satikusala 's heads up for straining computing power with too many agents as my Zettelkasten grows… (NOTE: It is also rather elegant, even if I doubt that I will succeed without more assistance)
This is really powerful stuff @mwra ! However, I get a problem when removing the value of some field in a completed note (i.e. all attributes and text field filled), so the “warning” badge return, and then fill the field again. Then the “warning” badge remains. If I manually remove all badges with a stamp, then everything works again.
The agents are the following:
aSet Badge “warning” to notes with an empty attribute or text field
If I add an agent above in the outline “resetting” the TBX by removing all badges to Prototype “pZettel”, then everything updates correctly. There are still much fewer agents than my original setup with one agent per Type and Domain (3+at least 4). Can I make it even more parsimonious by somehow getting rid of this additional “reset”-agent?
Don’t worry, there is this often this awkward phase when transferring action logic from first incremental efforts into a more consolidated structure.
You have a different scope for the second agent. Try the query:
Prototype=="pZettel" & ($Domain | $Type)
Now all matched notes, due to the first agent, all zettel notes will have a ‘warning’ badge if incomplete, or due to the second agent completed zettel notes with have one of three type badges (assuming all zettel notes are one of 3 types once complete).
At this point you are right to zero out the settings. This is why I always advise experimenting in a separate test file, even if it is just a copy of your main document. That way if you mess up, you can dump the test and start over.
BTW, when it gets to that point, if it ever does, I’ve found some neat tricks to debug my TBX. For example, you can under the file menu stop agents to run automatically. You can run an agent to disable Edicts and rules for a while and then turn them back on later. You can then open up the attribute browser and look at the action query, action, rules and edit attribute to try to eyeball where you mistake it. And, if things get really Squirrelly, or just for fun, you can (FIRST MAKE A COPY OF YOUR FILE AS A BACKUP) open up the TBX in a text editor like BBEDIT and look at or adjust the XML (DO AT YOUR OWN RISK, YOU CAN EASILY BREAK SOMETHING IMPORTANT).
It is this last point that I find so incredible about Tinderbox (we’ll all the points, but the last one in particular). Tinderbox give is standardized, accessible, access to your source. You have the ultimate portability to your raw data. Moreover, you don’t have to go rooting through ~library and looking for a bunch of arcane code. Just think about that for a movement. Tinderbox is one of the purest pieces of “empowerment” software I’ve ever come across.
That’s a very good advice. I am now playing around with a copy…
I still get the same issue of lingering “warning” badges, even after updating the query. Thanks for pointing out the benefit of focusing its scope, though!
However, I tried what you just taught me concerning setting colour and badge by applying an “if”-function, and read a bit in the Tinderbox Reference File about using the whole functionality of the " if(condition){action}else{action}}"-action code, and came up with this: if($Domain=="" | $Type=="" | $Keywords=="" | $Text==""){$Badge="warning"}else{$Badge=""}
I have tested it and it seems to accomplish what I need, without the extra agent deleting all badges at the start of all agent runs. Now I have two agents instead of I don’t know how many from the start
And, as you refine your thinking, what @mwra has taught me to consider as “incremental formalization,” you can go down to one rule or edict. You won’t actually need the agents. Again, not to say there is anything wrong with agents, just all depends on what you’re looking for. For example, agents create aliases, whereas rules and edicts don’t. If you don’t need the aliases, i.e. to get the aliases for other purposes or make edits on a discrete set of notes, then rules and edicts are your best bet. At least, I think I’m right or nearly right on this one.
Thanks for the tips! I may follow up on them, if I ever get that deep into it
I do agree with you completely concerning Tinderbox. The only regret I have is that I didn’t get into it earlier… Just imagine if I would have started using it when I was a gradstudent over in Edinburgh in 2002, and kept building on my Zettelkasten since then…
For this thing I don’t need the aliases at all, but that’s fine as long as their containers remain closed in outline view. Although I have the functionality I need now, I will have a look at using rules and edicts for it as well. Just for trying to learn more about the capabilities of the software. It must be a hell of a complicated code, though, so it may be out of my league for now
I hear you on this one…I’m trying to practice daily mindfulness on this and letting regret was away and around me. There is not value in it. Be grateful and thrilled that we have it now.
Thanks to both of you for not only teaching me how to use Tinderbox, but also how to think Tinderbox.