I too can’t replicate this based on the info supplied. IOW, the issue is likely an overlooked, undescribed, aspect of the file in question. Thus, it would be useful to see a test TBX file that reputably shows the error. The test case only needs 2 notes (a positive and negative match) and an agent) as it seems likely some unstated element is at play.
Taking another tack, you could try:
$Citation.beginsWith("(Wun");
N.B. this operator olny allows literal string matches, so no regex.
I had my $Citation attribute as a “set” not as a “string”. I created a test file as you suggested and it worked, which led me to figure out my error.
In my live file I changed $Citation from Set to String and it worked.
I would love to figure out how to search using partial words and wildcards on sets, however. For example, looking for “Priv” to capture any time that has “Privacy” in the $Tags set.
Maybe on our next Saturday call we can go over wildcard searches, including using operators like *, .*, etc.
Set and list comparison requires literals, not regular expressions, to void confusing partial matches. If you want to use regular expressions with set and list comparison, coerce the set or list to a string:
I’m not sure but, could this not be done on the fly without needing to pre-store the string-ified list? IOW:
$MyList.format(" ").contains("Frac.*s")
So if $MyList olds the values ‘Frantic’, ‘Fractal’ and ‘Frames’, the string tested by .contains() becomes “Frantic;Fractal;Frames”.
Indeed, using the test doc to check @satikusala’s problem, if I make $Citation into a Set and use a query $Citation.format(“;”).contains(“Wun”), it works. Here is the test: Set-check.tbx (79.2 KB). The agent sets the tested note’s $Text simply to prove the target string being tested by the chained .contains is a string. You don’t have to use a semi-colon concatenation (i.e. the default list item delimiter) but if choosing a not letter character don’t choose one with a regex meaning.
Expectation management: cClearly, if one scales this to using the method on 000s of notes each with large numbers of list items and using a complex regex, performance may be less snappy. I’d assume users working at this scale would expect such an effect, but I still think it warrants noting for those as yet only working in small docs where the issue is moot.
Waaay tooo much fun guys. Thanks. I’d like to add one more learning to this; Mark showed me this a couple of weeks ago.
You can use a designator “agent” so that the query will pull the search team from the $MyString. Works great. This is easier than messing with the query string. For those interested in playing with this, here is my test file WildcardSearch.tbx (133.4 KB).
Tinderbox code is sui generis, with a generous hat tip to C.
I don’t recommend reading a dry manual on regular expressions. Rather, get an app such as Expressions or one of a number of sites you can find via a web search that lets you try out expressions with sample data. Best way to learn regular expressions is hands on. You’re familiar with the drill.
Further to the last, as regex comes in many ‘flavours’ of implementation, in tools like the above use documentation of the Perl-style choice. I don’t believe there is a canonical reference as such. the basic regex forms seem common to most flavours. It’s only at the more exotic level (that few use) where differences of implementation come into play. Ergo, most general regex references will get you started.
After some years of use, I will say that if you can bear to do so, you get much more out of regex by taking time to see what they do and not simple copy/paste sections of ‘magic’ code. Regex are very precise, and in a manner often more granular in execution than our assumptions in writing them. Don’t worry about the odd-looking syntax but just remember ‘garbage in garbage out’. If it doesn’t work, esp in a spall localised test (I.e. no/less scope for edge cases) it likely means you haven’t yet found the edge case.
Thanks again, Paul. Is there a Syntax name for the methods used in agents and the export code? What do you call this type of coding, or are these methods a Tinderbox standard?
I too use Expressions, and similar apps in the past. Sometimes, just doing regex tweaking/tuning abstracted out into such an app can replace some small-scale testing in Tinderbox. If nothing else, it helps focus on the matching process. Sometimes the result is to relaise there may be a better/more efficient approach. IOW, if you need lots of very narrow-foccused regex, it might be Nature suggesting you revisit you’re doc’s attributes (metadata) and finding better ways to seed the strands you are trying to find.
Also, as a doc matures, it helps to keep revisiting any $Text.[i]contains() calls. My experience is that as a doc matures, abstracting these text ‘markers’ into attributes obviates the need to search all the $Text of many notes ‘just’ to find a narrow thread. That doesn’t mean to suggests its what everyone should do, but at least be open to the enlightened self-interest of leveraging attributes to help you hold nuances within your notes.
In About Tinderbox Actions that you authored, on page 2, you reference and highlight a book entitled, A Shortcut for Programmers. The link does not work and I cannot find the book/reference anywhere. Do you know who wrote it and do you have an active link?
Unfortunately my copy of About Tinderbox Actions only has 15 pages and looks like it is incomplete which explains the broken link. I found the first 15 pages helpful, now that I know there is more I am sure myself and others would enjoy the read.
Is there a link to the file that I can re-download?
Thanks Mark. I love these very concise, schematic presentations of aspects of action code (or other aspects of Tinderbox). It helps for the big picture. The rest I can get from the extraordinary “man pages” @mwra maintains.