This doesn’t have anything to do with sort ordering though, which is based on time and votes. Text search is just a filter on top of sorting.

You want exact word matches prioritised ahead of entirely unrelated words that include the same characters. Like “enum” should turn up your comment, but rank a comment that contains the text “renumbers” much more lowly. A particularly smart search page might keep “enumerate” high while rejecting “renumbers”, though.

Of course, it’s true that at least in the current latest release, Lemmy fails at all of this. I hope 1.0 is at least fixing some of it?

How Lemmy does text search is via pg_trgm which works by breaking down both the content text and search text into trigram* and if the content contains enough of the search trigrams, it’s considered to match the search term.

* A trigram is just a 3 character ‘words’, for example the trigram of ‘enum’ is {" e"," en",enu,num,"um "}.

What you’re describing is closer to a tsvector, so you could open up an issues on Lemmy’s GitHub to move from trigram to tsvector. One advantage trigrams have though is that they’re language agnostic while tsvectoss need both a dictionary and to know the language (thankfully, Lemmy already has this info via the language setting, though the way it’s stored will need to be changed to accommodate this). But tsvectors does provide much more intuitive language matching, like what you outlined.