Straight off the bat: I don't like option 3. If I've provided multiple words, it's very unlikely that I'm going to be meaning "this or that", it really fucks me off when public search engines decide to ignore words in the search term I provided.
If we go with either option 2 or 3 we'll probably want to implement support for quoting (so that option 1 can be achieved).
In the absence of quoting, I think an implicit AND makes most sense
Now would also, probably, be a good time to move the search logic out of the portal and into a dedicated module - allowing a CLI to be created later (if desired)
Activity
29-Dec-23 11:51
assigned to @btasker
29-Dec-23 11:54
Straight off the bat: I don't like option 3. If I've provided multiple words, it's very unlikely that I'm going to be meaning "this or that", it really fucks me off when public search engines decide to ignore words in the search term I provided.
If we go with either option 2 or 3 we'll probably want to implement support for quoting (so that option 1 can be achieved).
In the absence of quoting, I think an implicit
AND
makes most sense29-Dec-23 11:54
changed the description
29-Dec-23 11:55
Now would also, probably, be a good time to move the search logic out of the portal and into a dedicated module - allowing a CLI to be created later (if desired)
29-Dec-23 12:02
mentioned in commit 1d0cf5501e433b7e14ba1b8c0792cde69655270e
Message
chore: move search function to dedicated module (prep for utilities/file_location_listing#12)
29-Dec-23 12:13
mentioned in commit c4cb39872fdedcd11a87d3775ccd61cb88744eec
Message
feat: Implement AND behaviour for multiple search terms (utilities/file_location_listing#12)
29-Dec-23 14:03
mentioned in commit 755a94d0dd203639084b50ecbd310278e59e9bea
Message
feat: add an exact matching mode (utilities/file_location_listing#12)
29-Dec-23 14:04
I decided that adding support for quoting was too much of a PITA, so instead I've added a
mode
operator:Will only return results where the phrase "concrete posts" appears