The cached order position introduced in 42e9ac5 is incorrect
as it does not consider the case when we are viewing any
other result page than the first.
Fix this by considering which page we are in when calculating
the offset
Previously, the order of previews would depend simply
on which generator would finish first.
Fix this by caching out of order previews. This may
cause a small delay but should overall be hardly noticable.
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.
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
Not entirely ideal, since we may want to search for 'cake', and look at
a preview for 'cake.txt' even if there is no 'cake' inside.
But this will do for now
This prevents 'spam'. User may have scrolled 10 pages forward, while
we are still generating old pages. Then the user wonders why
they arrive so late.
So disable switching pages while the generation is still running
It is unlikely that a user will have to quickly go through search
results like that.
