NOT operator doesn't seem to work

I have used a search

“tags:GAP scope:mydatabase”

and found 4 documents of around 1100 items in “mydatabase”.

Now I read in the search appendix of the manual about the NOT operator and I try:

“NOT tags:GAP scope:mydatabase”

and I get no results. – I expected all other documents (i.e. more than 1000 items) to be returned.

Even taking out the “scope” qualifier (i.e. searching in “All Databases”) does not return any documents.

What’s going wrong?

“NOT tags:GAP scope:mydatabase”

  • Where did get this syntax?
  • And are you actually quoting the whole thing?

That’s the wrong syntax, the right one is tags:!GAP. See documentation for complete description of syntax.


If NOT tags: GAP were a thing, it would find all entries where something is “GAP”, but that something is not a tag. For example, it would find entries containing “GAP” in their name. Which explains why NOT <prefix> is not a thing.

1 Like

I got this syntax from the manual: In the Appendix , Section “Search operators”.

No. Sorry that’s misleading.

Thanks a lot for this! Very constructive advice. Will try it.

So the logic “not tag is GAP” doesn’t work, but “tag is not GAP” does… Good to know.

BTW, I did find “NOT” in the documentation (pdf manual) under the section “Search operators”.

1 Like

It might work, but not as you want it to. Which is to be expected.

In Boolean logic, the NOT operator negates the following predicate. In your case, the predicate would be tag is GAP. Consider the house is blue. Saying not the house is blue is very different from the house is not blue.
In the first case, you’re talking about everything that’s blue and not a house (“not the house is blue, my eyes are and my car is”).
In the second case, you’re talking about a house that has another color than blue.

No doubt. But in the documentation, “term” means “search term”, i.e. “GAP” in your context. Not “search expression” (like not tags: something). The same goes for AND and OR etc.

I find the usage of the word “term” a bit unfortunate here, as it has a very different meaning in mathematical and logical expressions. And that might lead to the false expectation that the boolean operators will work with expressions.
For the sake of clarity, using “search term” might be better in that place.

1 Like

BTW, I did find “NOT” in the documentation (pdf manual) under the section “Search operators”.

Where exactly?

Thanks. Good to know about :!.

DEVONthink 3.9.4 Documentation, page 231

I fully agree. The choice of words tripped me up. (Although, I was only “search-skimming” the manual, not going through the whole chapter. So, if I had read the whole chapter I might have understood better what’s meant with “term”…)

Sorry, I don’t get this (though I want to understand it). – The logical expression NOT (tag is GAP) should find any document which does not have a tag equalling GAP, shouldn’t it?

Yes and no.
Yes, It should in a context where not is a real Boolean operator. In that situation, it’s equivalent to tag is not gap. Note, though, that you’re using parenthesis here – that makes not negate the whole expression. Without the parenthesis, it would (perhaps) negate tags, like in (not tags) is gap. „Perhaps“, because tags might not be a Boolean expression and thus can’t be negated.
Like in the context of DT.

Which brings me to the „No" part. DT does not follow the model of Boolean logic with its search operators: They are not applied to expressions but to search terms.
text: me AND you
is valid DT syntax
text: me AND tags: you
is not. and is implied between all search expressions. You’d have to use any: to have DT or expressions together. And there’s no equivalent for not to combine expressions – you have to use a negative operator for that.
text: me tags:! you works
text:me not(tags: you) doesn’t

Personally, I’d like a more „logical“ logic in that context (which would reduce the number of operators, too). But most people are probably happier with what DT does now.

Which is, btw, very similar to what lots of apps do. Implementing an interface for arbitrary logical expressions is hard if not impossible.

1 Like

Thanks for all the details. The distinction between expression and search term makes sense.