In [1] it's stated that "If the values "inserted" into the text
columns as part of a 'delete' command are not the same as those
currently stored within the table, the results may be unpredictable."
It's to be assumed only inserting ftsid is unpredictable. We
have no way for a proper delete because files are not immutable
or may have been deleted.
For now the index will contain entries for files that don't exist.
They won't appear in search results as they won't be joined
in the query.
[1] https://www.sqlite.org/fts5.html#the_delete_command
Since 7c5c91e we wrongly merge lone words for paths queries too.
This creates unintended behaviour.
Fix it by creating a new paths query without merged words, which
restores the original behaviour.
Also, get rid of some redundant calls to createFinalTokens()
Avoid double results in search by distinguishing whether
a filter was explicitly given. Previously, we could not
discern this.
Furthermore, if a content search is given, lone words will be
considered path searches. If a path search is given, we consider
lone words implicit content search filters. This simplifies
queries for the user
Most users are not to be expected to be familiar with
sqlite's FTS syntax. It also leads to unnnecessary
arrows in some instances.
So wrap every space separated word in quotes, unless
it's already in quotes. Then we just escape those with
double-quotes.
We never used the content copy we stored. It only wasted space.
Update scheme so we do not store the content anymore. Switch
to contentless FTS approach
Running migrations is okay for initialization. However, doing
it here might take ages, so the GUI simply would not show up.
Therefore, migration must be done by the CLI or GUI and they
should show that migrations are running
We get OK_WASEMPTY from the processor when there
usually should be something. Rarely, this is not the case.
Let the callers know about this state at least
