Using "contains * " as in the screenshot doesn’t seem to work, i.e. doesn’t return any results.
For now I’ve entered a blank character, which is a sufficient workaround since that field almost never contains only a single word (and therefore if there’s data it will also contain a blank character).
Is there a cleaner way to achieve this? Thanks in advance.
I don’t know. Maybe it would be helpful to allow empty text fields or a catchall wildcard like * for predicates. I suspect that the whole predicate system is modelled after AppleScript’s whose|where implementation (or rather NSPredicate). But that should allow testing for empty strings – so it’s probably just a limitation of the UI.
It would also help to add regular expressions to all string comparisons, including metadata. Then ^$ would match empty strings, and one would need match|does not match predicates. Not to mention that regular expressions would effectively make the contains, begins with, ends with stuff unnecessary.
Since NSPredicates does offer a matches operator evaluating regular expressions, that shouldn’t be too difficult to add (I hope). And DT is already using that, albeit only with name and content in the Scan name and Scan contentactions.
I hope that they’ll eventually add (does not) match predicates to all the string comparisons in the smart rule conditions section.
if they want to make it as easy as possible with the potential disadvantage of longer pull-down menus: yes, entries for (not) empty might make sense
if they want to provide a concise and comprehensive selection of predicates, match regular expression and a negation toggle would be sufficient. With the disadvantage that DT users have to learn regular expressions.
I’d go for the middle ground: allow empty text fields as input (or a placeholder like empty) with an is predicate, add a negation toggle (thus eliminating the ‘not’ predicates from the menu), and add a match predicate using regular expressions. That would keep the menu short and not force people to use REs but enable them to do so.
But then I have a mathematical background, and it’s not me who has to code the stuff.
So it looks like there was at least some level of user error involved in my initial approach
From a different thread:
Therefore, of course "contains * " was never going to work. I’ve now come up with the solution below to include all items in the smart group that begin with any letter. So compared to the previous workaround of using a blank character, this will also include items if they only contain a single term in the metadata field. In any case, I’m happy with the result
With any lowercase letter in the english alphabet
While your approach might work for your documents, it is still a kludge because DT is missing the necessary predicates. A “clean” solution would use either “is (not) empty” or a regular expression “(does not) match $^”. Which would then also work for other languages with accented characters or in a completely different writing system.
Always happy to stand corrected and learn In this case though, it doesn’t appear to be true that only lower-case letters are in scope for the smart rule. It seems to work regardless of whether the term in the metadata field starts with upper or lower case letters.