X-Git-Url: https://git.notmuchmail.org/git?p=notmuch;a=blobdiff_plain;f=notmuch-index-message.cc;h=4585a3b98905d03d44252f7a88d55b2c06f76f23;hp=3bb62f659dcdc29515bb03c616a56db569b586a3;hb=bae1ce09a37071cdf592048938319c72653e96e0;hpb=27c01802c89fb825c144ead13de0f6d6437ba997 diff --git a/notmuch-index-message.cc b/notmuch-index-message.cc index 3bb62f65..4585a3b9 100644 --- a/notmuch-index-message.cc +++ b/notmuch-index-message.cc @@ -17,6 +17,38 @@ * Author: Carl Worth */ +/* This indexer creates a Xapian mail index that is remarkably similar + * to that created by sup. The big difference, (and the thing that + * will keep a notmuch index from being used by sup directly), is that + * sup expects a serialized ruby data structure in the document's data + * field, but notmuch just puts the mail's filename there (trusting + * that the email client can get the data in needs from the filename). + * + * Note: One bug here is that sup actually merges together fields such + * as To, CC, Bcc etc. when finding multiple emails with the same + * message ID. To support something similar, notmuch should list + * multiple files in the data field. + * + * Other differences between sup and notmuch-index identified so far: + * + * o sup supports encrypted mime parts by prompting for a passphrase + * to decrypt the message. So far, notmuch doesn't support this, + * both because I'm lazy to code it, and I also think doing so + * would present a security leak. + * + * o sup and notmuch have different heuristics for identifying (and + * thus ignoring) signatures. For example, sup considers a line + * consisting of two hypens as a signature separator, while + * notmuch expects those two hyphens to be followed by a space + * character. + * + * o sup as been seen to split some numbers before indexing + * them. For example, the number 1754 in an email message was + * indexed by sup as separate terms 17 and 54. I couldn't find any + * explanation for this behavior and did not try to replicate it + * in notmuch. + */ + #include #include #include @@ -269,12 +301,23 @@ static void insert_thread_id (GHashTable *thread_ids, Xapian::Document doc) { string value_string; - const char *value; + const char *value, *id, *comma; value_string = doc.get_value (NOTMUCH_VALUE_THREAD); value = value_string.c_str(); - if (strlen (value)) - g_hash_table_insert (thread_ids, strdup (value), NULL); + if (strlen (value)) { + id = value; + while (*id) { + comma = strchr (id, ','); + if (comma == NULL) + comma = id + strlen (id); + g_hash_table_insert (thread_ids, + strndup (id, comma - id), NULL); + id = comma; + if (*id) + id++; + } + } } /* Return one or more thread_ids, (as a GPtrArray of strings), for the @@ -368,8 +411,8 @@ gen_terms_body_str (Xapian::TermGenerator term_gen, } line_end = next_line - 1; - /* Trim whitespace. */ - while (*next_line && isspace (*next_line)) + /* Get to the next non-blank line. */ + while (*next_line == '\n') next_line++; /* Skip lines that are quotes. */ @@ -401,6 +444,7 @@ gen_terms_part (Xapian::TermGenerator term_gen, GMimeStream *stream; GMimeDataWrapper *wrapper; GByteArray *byte_array; + GMimeContentDisposition *disposition; char *body; if (GMIME_IS_MULTIPART (part)) { @@ -427,6 +471,27 @@ gen_terms_part (Xapian::TermGenerator term_gen, return; } + disposition = g_mime_object_get_content_disposition (part); + if (disposition && + strcmp (disposition->disposition, GMIME_DISPOSITION_ATTACHMENT) == 0) + { + const char *filename = g_mime_part_get_filename (GMIME_PART (part)); + const char *extension; + + add_term (term_gen.get_document (), "label", "attachment"); + gen_terms (term_gen, "attachment", filename); + + if (filename) { + extension = strchr (filename, '.'); + if (extension) { + add_term (term_gen.get_document (), "attachment_extension", + extension + 1); + } + } + + return; + } + byte_array = g_byte_array_new (); stream = g_mime_stream_mem_new_with_byte_array (byte_array);