Search the trigram index too, combining the results
with the results of the "normal" fts index.
Prioritize the latter since it makes more sense to
rank whole words higher.
Processing dirs with large docs takes time and waiting till the threshold
is reached can be a bit annoying in those cases, so report if last report
was 10+ seconds ago.
We use this semi-HTML mode to highlight words, but if we already
have tags in the document this does not work quite well.
Thus, escape the string before further processing it
The current snippet selection is useless for many queries.
Attempt a more reasonable snippet selection by prioritizing
those where all words are contained. The more words a snippet
has, the more important it is considered.Therefore, those will
be at the top.
Only highlight whole words
Crashes were observed, faulting in libQtNetwork.
Those were rather rare. We also have no traces.
Probably depends on some order signal/slots were
processed. Remove shared states between connections,
such as the IPCPreviewWorker and socket instance in IPCServer.
group_concat() does not preserve order of the ORDRE BY rank,
making the ordering quite meaningless for pages inside a file.
The recently introduced combobox to filter on a per file basis
should anyway be prefered than any kind of grouping in queries.
So we just remove the groupings here.
"All files" in the previews tab thus should show the best results
first now, from any files part of the result set.
A GUI option to sort by page instead of rank can be considered.
Indirectly generation would fire when we set combobox index
programitcally. So it's slot should only trigger the generation
when the user is viewing the preview tab
Add shortcuts to make entering queries more efficient
CTRL+F: Highlights rightmost filter, e. g. c:(word1 word2) would
highlight everything between (), so "word1 word" here. Alternatively,
highlights lone words, so p:(docs) word1, would highlight word1.
CTRL+W: Removes last filter or words.
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
Albert S.