For the (rare) messages without a Date: header, attempt to guess a date
from the top (most-recent) Received: header. Not perfect, of course, but
better than nothing.
Requires re-indexing to apply to already indexed messages.
Should help for #1083.
Move the various seq_ functions, as well as std::(stable_)sort,
std::accumulate, std::transform, std::find, std::find_if to their C++20
std::ranges counterparts.
Update various places for what we can do with C++20:
- ends_with / starts_with
- std::to_array
- using instead of typedef
- designated initializers
- "[[maybe_unused]]" instead of G_GNUC_UNUSED
Also remove some unnecessary 'static'
Do not consider calender-invitations "attachments"; do mark as
"calendar". Do recognize application/ics as calendar messages.
Update mime-object to expose a message part's disposition.
Change the "is-attachment" heuristic to include inline parts if they
have a filename parameter in their content-disposition.
Note that this doesn't change things radically; the delta is +69 and
-202 for ~6500 attachments.
Flag message that merely have a List-Unsubscribe header with
Flags::MailingList too (some marketing message have this header, yet
miss "List-Id".
Add a test as well.
Xapian supports an "ngrams" option to help with languages/scripts
without explicit wordbreaks, such as Chinese / Japanese / Korean.
Add some plumbing for supporting this in mu as well. Experimental for
now.
We were dumping the HTML-parts as-is in the Xapian indexer; however,
it's better to remove the html decoration first, and just pass the text.
We use the new built-in html->text scraper for that.
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.
Take an optional index parameter for a *subpart*.
This is for the case where we save attachments from a message (in particular,
when forwarding). We can't save them in the same directory for the (rare) case
when there are multiple attachments with the same name. And we don't want to
uniquify the name, since that shows up in e.g. the forwarded file name.
This can be solved by saving each in their own indexed subdir.
