Previously, we would conduct regular expression searches by
enumerating all values of a given term, manually regex-matching each
one against our search regular expression, remember all the term
values that matched our regular expression, then do a big Xapian
OR-query that matched any of those term values. In constructing this
OR-query, however, we would split each term value on space and add a
separate Xapian phrase search term for each resulting word. This
approach worked fine most of the time, beacuse when we index a term,
we index both each word in a term and the whole term by itself.
This word splitting produced false negatives in some matches, however,
because Xapian and the Mu-level word splitting code do word splitting
slightly differently and apply different transformations to the text
while splitting. (For example, Xapian transforms fancy Unicode
apostrophes to ASCII apostrophes.)
This patch avoids the problem by not word splitting when constructing
the big Xapian OR-query for finding the results of regular
expression matching.
Previously, mu generated a fake message ID for messages without a
Message-ID header. This fake message ID allows these messages to show in
an --include-related query. However, if a message contained a Message-ID
header with the value equal to the empty string, we did not generate a
fake message ID in the index, and consequently, these messages failed to
appear in an --include-related query. This change uses a fake message ID
when the Message-ID header is absent _or_ empty.
Since 2008, autotools has served us well - thank you!
However, mu is now using meson build, and it's time to remove the
autotools support -- one build system is enough.
Clean up the implementation at bit, and filter out 'fake' message-ids,
such as the ones from protonmail.
Update documentation.
Add Mu::Message::thread_id().
This fixes#2312.
1. Also add 'normal' terms for some indexable fields
2. Add terms for e-mail address components
And add some tests.
This helps for some corner-case queries (see tests).
Fixes#2278Fixes#2281
