Search for exact phrase?
Is there a way to search for an exact phrase, e.g., "this app is cool"? It's not always helpful to have 20 notes pop up because some contain the word "app" and others contain the word "cool." If I know the exact phrase I'm searching for, and only one note has that exact phrase, surely there's a way to get nvU to display just the one note?
-
Indexing happens by word, so there is no way to do exact phrases.
0 -
Hmm...that may prove challenging the more I use this app and add notes to it. Maybe I'm being dense, but it's difficult for me to quickly find the exact files I'm looking for. I'm often left with a list of 8-10 files that match my search criteria, and with no way to restrict search to file name, and no way to find exact phrases, I may have to click around on files to find the one I'm looking for. I appreciate the fast searching, but I wish for more effective ways to narrow the results of my searches. Of course, this may be mitigated once the search documentation is completed and I learn how the experts do it. ;)
0 -
As of the latest beta you can surround a search in double quotes to search for exact phrases. Give it a try and let us know how it works for you.
1 -
YES! It works! Thank you so much!
0 -
As an extra comment -- exact phrase matching is not compatible with complex boolean searches. It only works if the phrase is the only thing in the search bar.
Because of the way indexing is done, it might be overly complex to allow exact phrase matching as part of the boolean search parser, but if a reasonable approach comes to mind, I'll look at expanding that.
0 -
Any way to make this ignore case?
0 -
You asked for exact match and you got it.
:)
Short answer is "No". Longer answer is, "Of course -- computers can do anything." Complete answer is that doing a non-exact match requires a different strategy than an exact match, which complicates things. It's more likely that case insensitive "almost exact" matching would be considered if there is a way to integrate it (with reasonable effort) with the boolean search parser.
But as soon as we do that, then someone else will say that when they ask for an exact match, they want an exact match, which includes case sensitivity. So we would have to support both strategies. Also -- nvUltra is not designed for "librarian-quality" complex searches. It's designed to quickly find files that match certain words without having to search each file each time, and that doesn't require an index that is as long as the original file we're indexing. And while we don't have an iOS app yet, the indexing/search strategy needs to be reasonable for an iOS device as well. The goal of nvUltra is not to replace DEVONthink, which is phenomenal for search.
0 -
Hi Fletcher and Brett,
> *It's more likely that case insensitive "almost exact" matching would be considered if there is a way to integrate it (with reasonable effort) with the boolean search parser.*
Understood. Am adding a +1 here should that ever turn out to be the case (couldn't avoid the pun).
Also, a couple of opinions for your consideration:
1. I believe if users were offered phrase searching but required to choose between a case-sensitive and a case-insensitive search, the vast majority would choose the latter. In most use cases, especially when searching a small-ish number of common-ish words, the benefits of being able to enter a phrase search would easily outweigh the number of false positives that may be returned by ignoring case. (This all assumes booleans and regex are off the table, of course.)
2. I believe the current implementation of phrase searching may inadvertently trip some people up. It did me. Trained by other apps (including nvAlt) -- as well as by nvUltra's case-insensitive word searching -- I was surprised to discover today that "roof rack", "Roof rack", "Roof Rack", and "roof Rack" each returned different results. My expectations about how it worked were wrong, obviously, but I'm guessing this might not be an entirely uncommon occurrence. Perhaps a flag or note or hover text or message in the preferences or something might be helpful for your users.
Anyhoo, I've read up on your index search implementation and the challenges presented by phrase/multi-word searching -- and realize that nothing I'm typing here is something you don't already know -- but wanted to add my vote and voice to the chorus.
Cheers,
Sam.0 -
I'm digging into this further. One possibility might be a "two-tiered" search approach. After using the normal approach to find matching notes, a second pass can be performed to check matching notes for an exact match of the target phrase in double quotes. This will necessarily decrease performance (depending on number of potential matches, this may or may not be a significant decrease.)
For example, searching for `"foo bar"` would first find matches for `foo` and `bar`, then filter those for documents containing exactly the phrase `foo bar`.
We'll see if it pans out as a feasible technique.
1 -
Thanks for the reply and update, Fletcher.
Not that I know anything about the challenges of implementing it, but that 'filter-all-for-words-then-filter-results-for-phrase' approach sounds like a pretty great idea. I will keep my fingers crossed.
Cheers.
0
Please sign in to leave a comment.
Comments
10 comments