To see it in action:
Crust.piefed.social (the Piefed development instance)
Not all instances implement it yet, I guess it depends how often they pull from the dev branch
Example of search for ‘movies’
To see it in action:
Crust.piefed.social (the Piefed development instance)
Not all instances implement it yet, I guess it depends how often they pull from the dev branch
Example of search for ‘movies’
That doesn’t feel like how search should work. It should be ranking results that fit the search query better higher than ones that fit it less. Regardless of how the search is done, that should remain true. So if you’re using trigram matching, instead of a binary “does the comment contain 80% of the trigrams in the search query”, it should be “if it contains 100% of the trigrams from the search query, rank it higher than something with 90% match, which is higher than 80%.” Or maybe not that precisely, but something so that more relevant results appear above less relevant ones.
Without doing something like that, it’s just…not very useful. Which is the observed behaviour of search on Lemmy right now which started this whole conversation.
But the existing filters already prescribe an order outside of how closely the search term matches, you brought up top month and I don’t see how you’d want that to work other than a binary filter sorted by votes.
What you’re describing would be a new sort order, analogous to Reddit’s ‘Relevance’ sort. It’s certainly doable with postgres’ builtin distancing operators, though it be slower.
The truth is I don’t want “top month”. What I really want is “best result, filtered by this month”. But unfortunately that doesn’t exist, and in the absence of that, I use “top month”.