This caps the search results at 1000 emails, due to our unfortunate
requirement of constructing an object for each search result. A better
way to proceed here would be to do the search only as items were loaded
in the SearchFolder, but that gets complicated when the search phrase
gets updated.
This adds an async queue processor in the background of the conversation
monitor to handle work items serially. Instead of the conversation
monitor directly running its operations, which would have the potential
to overlap, this ensures they happen in the correct order without
trampling on each other. This way, one operation isn't adding emails
that a prior operation had already removed the conversations for, for
example.
Won't close this quite yet because this workaround shouldn't be
necessary, and introduces a memory copy when dealing with message
headers and bodies, which we'd like to avoid.
It looks like when Glade saved the toolbar.glade file recently, it
overwrote some apparently-necessary defaults. The end result was that
one of our helpers was crashing because the gear menu button was getting
a null label. If we explicitly set the label in the action, it seems to
make it happy. This is preferably to undoing the change in the .glade
file because if we did that, the next time someone saved it, it'd just
break again.
There was a bug before where our Nonblocking.Mailbox's priority queue
wasn't actually being created correctly. This fixes that. Sounds like
this might affect lots of things, especially the order in which the
background fetcher syncs folders.
This introduces an STMP authentication fallback scheme. It first
attempts advertised schemes, then falls back to unadvertised (but
commonly-implemented) schemes. In particular, this is to deal with
certain servers that advertise support for an authentication scheme
but not actually implement it.
The nuclear option: rip out *all* Message-IDs in the reverse-lookup
map in ConversationMonitor, not merely the Message-IDs of the
remaining emails in the conversation.
One reason this is appropriate: if the conversation contained
reference to an email that was never received by the user, that would
cause a Message-ID to linger in the reverse lookup table, making a removed
conversation appear like it's not new when another email for the
conversation arrives.
We use the list of preferred languages for the user at the time of
search table creation to pick the most relevant stemming algorithm for
our search tokenizer. If we don't find a stemmer that matches any
preferred language, we use the English stemming algorithm as the
default.
The idea is to have one query syntax that Geary respects, and be able to
use it in SQLite, over IMAP, etc. This is the SQLite version that
translates what's in the search bar into a more permissive search
against the local database.
