I think I’m probably missing something simple, but how can I search for more than one term at a a time, e.g. “infant” AND “grooming” (finding notes with both words, but not both words as a single phrase) or excluding certain terms, e.g. “infant” NOT “Dunbar” which would exclude all notes containing the word infant that were written on/ by “Dunbar.”
So far it seems to me that I can only look for single phrases or keywords, but I suspect I’m overlooking something obvious here.
Thanks!
Aliza
Hi,
You can change the search parameters by clicking on the arrow next to the magnifying glass in the search field in the tool bar. By default it’s set up to “Exact Phrase”, but you can change that to “All Words” or “Any Word”. There’s no way of excluding a word from a search at the moment, though, and no true boolean operator search. I may look into something like that post-2.0 though.
Best,
Keith
Thanks, that’s perfect 
Keith,
I was just wondering if there has been an update on this topic. I would love to be able to exclude something from my search. For example, at this very moment, I need to search for all notes that do NOT have their status set to “Done.”
Is there a way to do this?
No, there’s no way to do this. It’s on the list of vague plans for the future, though.
Actually it is (mostly) possible to search with NOT, using regular expressions. Set the search mode to “ReGex” and type in: [^Done]. You can exclude multiple words by separating them with a pipe symbol (representing OR logic) in between the brackets. [^Done|NA] would find everything that is neither Done nor NA. The thing to note is that you’re searching for characters, really not words. [^nDoe] would work just as well. So long as you don’t have any anagrams in your search list it should be fine.
I was about to reply again and say the same thing - that RegEx could be used for this.
Ioa, I’m no RegEx expert, so I had to look this up, but I saw the recommended search term as “^(?!done$)”, and oddly I got different results using that than “[^done]” - search for “chapter” on labels in the tutorial project, for instance, and “[^chapter]” doesn’t seem to bring up all the results it should…
That should be more robust, looking at the mechanics of it. The method I was thinking basically declares a set and then specifies all of the letters of the word as that set (the ‘^’ at the front of the set declares it as a negative set). So long as every label is composed of a unique set (rather than string) of letters it should work.
The method you found uses a negative look-ahead clause. That means, find this, but only if it is followed by that (without considering that to be a part of the match, only consider it necessary for the match—which isn’t relevant here, but means in a search and replace context, the ‘done’ part of this would not be replaced, only considered necessary for the rest of the pattern to be matched). In this case, the this is ^ which signifies the beginning of a line. By itself that will match everything of course, but we only want to find line-beginnings that are NOT followed by the sequence of characters, done. The dollar sign, which signifies end-of-line, ensures that ‘Done - Sent’ is not also returned.
As for inconsistencies, I didn’t find anything odd there. Both [^chapter] and ^(?!chapter$) return a 34 length list of results that appear identical when flipping between them (saved as collections to make that easier), and in turn both of these match a list I created by hand that only contains items marked as “Chapter”. But, as I say the look-ahead method should be more reliable and elevate the answer to, “Yes you could do this”, rather than “Sorta”. So maybe you ran into one of those unreliable scenarios with the simple set method, though I’m not sure why we’re seeing different results with the same data set.
I got this too, or at least I got another problem. The look-ahead search is returning the Draft, Trash, and Research folders.
Haha! And then I got it to crash by searching ^(?!). Whoops. (Reproduced it too, on two separate computers, but let me know if you need a crash report.)
Yes, I do get the special folders as well, maybe that’s behind the numerical discrepancy, and why I didn’t see it since I did all of my counting using methods that stripped out those three folders (selecting the search result list and hitting + to make a new collection from it will strip out invalid requests to do so). However it appears possible to find the root folders with normal searching too. All-Exact search for “Draft” will return it.
I also get the crash with the invalid search syntax. If you were trying to search for anything that doesn’t have a label (or an empty label), use ^$ alone. That will look for lines that start and end immediately. Searching for “No Label” (or whatever the ‘X’ label is renamed to) with normal operators would be more efficient.
Hm, I remember emailing about search results returning special folders a while ago, so that may actually already be on the list and fixed for next release.
I wasn’t actually intending to search for a blank, I was just deleting the text in order to replace it, but because of the real-time search, the crash happened before I could enter the new text.
I haven’t read this latest discussion carefully so forgive me if I’m just introducing noise, but I see in some of the posts that you’re trying to search for words using regex character sets. [done] looks for anything that contains d, o, n, or e while [^done] looks for strings which contain none of those letters. So [^done] would exclude the statuses (if that’s the field being searched exclusively) “done” and “redo” because of the common letters d, o, and e. Really they’d only have to contain one of the letters to be caught by this expression.
I don’t know the actual solution to finding words that do not match a given list, though I’ve noted that negated word searches in regular expressions can be tricky at best, and some implementations can’t perform them at all. I often resort to using egrep -v on the command line or perl scripts with an “unless (regex) {#do stuff}” selection statement (a variation on “if (not ( true statement)) then…” )
Anyway, I thought it best to make sure it was clear that the square brackets in regexes are just lists of characters to match (or not) and shouldn’t be confused with word matches. Best of luck with the crash bug!