Poor search handling

Former poor search handling in dclib

A significant bug, yet no-one besides me reported it. Either no-one noticed, no-one cared, or they just didn't actually report it somewhere I might notice. Maybe everyone liked returning fewer search results.

So, what was wrong with dclib's search handling?

dclib ignored components of search queries that were shorter than 3 characters.
dclib did not search in the file path, just the name.
dclib did not match by substring, it needed an exact match between a component of the filename in the index and a component of the search query.

dclib ignored 1 and 2 character components of search queries because it couldn't handle them properly, without the substring matching. Without the substring matching it couldn't handle longer searches properly either.

Probably, dclib was optimized to handle the typical search, which consists of a single, long, complete keyword. With unfortunate problems for other searches.

If you searched for "lost 5 1", the results dclib returned most likely don't match 5 and 1.
If you searched for "chick", dclib does not return any files with "chicks" in the name.
If you organise you files where some info is in the folder name and not in the file name, dclib probably couldn't find it.
If you searched for "10" you didn't get any results, but didn't really deserve any for a such a stupid search.

This was not fixed properly until 0.3.19. In addition, handling characters other than ascii a-z case-insensitively properly was also added.

This was only fixed by completely removing all the code that did "lookup by keyword" and "keyword indexing" or whatever, and replace it with some other code to handle searches. It didn't have to be particularly fast or clever, it just had to actually return useful search results.

The "remove all the existing code and replace it with something else", something else that works, makes sense, is readable etc. should probably have been taken as a hint for what to do with the rest of dclib.