Add destroy functions for results, message, and tags.

None of these are strictly necessary, (everything was leak-free
without them), but notmuch_message_destroy can actually be useful
for when one query has many message results, but only one is needed
to be live at a time.

The destroy functions for results and tags are fairly gratuitous, as
there's unlikely to be any benefit from calling them. But they're all
easy to add, (all of these functions are just wrappers for talloc_free),
and we do so for consistency and completeness.

Rename our talloc destructor functions to _destructor.

I want to reserve the _destroy names for some public functions
I'm about to add.

Implement 'notmuch dump'.

This is a fairly big milestone for notmuch. It's our first command
to do anything besides building the index, so it proves we can
actually read valid results out from the index.

It also puts in place almost all of the API and infrastructure we
will need to allow searching of the database.

Finally, with this change we are now using talloc inside of notmuch
which is truly a delight to use. And now that I figured out how
to use C++ objects with talloc allocation, (it requires grotty
parts of C++ such as "placement new" and "explicit destructors"),
we are valgrind-clean for "notmuch dump", (as in "no leaks are
possible").

Rename private notmuch_message_t to notmuch_message_file_t

This is in preparation for a new, public notmuch_message_t.

Eventually, the public notmuch_message_t is going to grow enough
features to need to be file-backed and will likely need everything
that's now in message-file.c. So we may fold these back into one
object/implementation in the future.

Makefile: Add automatic dependency tracking to the Makefile.

With this, I really don't miss anything from automake.

notmuch: Fix setup so that accepting the default mail path works.

The recent change from GIOChannel to getline, (with a semantic
change of the newline terminator now being included in the
result that setup_command sees), broke this.

message: Use g_hash_table_destroy instead of g_hash_table_unref

I'm trying to chase down 3 still-reachable pointers to glib hash
tables.

This change didn't help with that, but I think destroy might be a
better semantic match for what I actually want. (It shouldn't matter
though since I never take any additional references.)

add_message: Fix memory leak of thread_ids GPtrArray.

We were properly feeing this memory when the thread-ids list was not
empty, but leaking it when it was.

Thanks, of course, to valgrind along with the G_SLICE=always-malloc
environment variable which makes leak checking with glib almost
bearable.

database.cc: Document better pieces of glib that we're using.

message.c: Free leaked memory in notmuch_message object

We were careful to free this memory when we finished parsing the
headers, but we missed it for the case of closing the message
without ever parsing all of the headers.

notmuch: Use GNU libc getline() instead of glib GIOChannel

Less reliance on glib is always nice for our memory-leak testing
efforts.

notmuch_database_open: Fix error message for file-not-found.

I was incorrectly using the return value of stat (-1) instead of
errno (ENOENT) to try to construct the error message here.

Also, while we're here, reword the error message to not have
"stat" in it, which in spite of what a Unix programmer will
tell you, is not actually a word.

Add some explanation about NOTMUCH_BASE to setup_command.

Since we allow the user to enter a custom directory, we need to
let the user know how to make this persistent. Of course, a better
answer would be to take what the user entered and shove it into
a ~/.notmuch-config file or so, but for now this will have to do.

notmuch_database_create/open: Fix to handle NULL as documented.

When documenting these functions I described support for a
NOTMUCH_BASE environment variable to be consulted in the case
of a NULL path. Only, I had forgotten to actually write the
code.

This code exists now, with a new, exported function:

     notmuch_database_default_path

notmuch_message_get_header: Fix bogus return of NULL header.

A simple bug meant that the correct value was being inserted into
the hash table, but a NULL value would be returned in some cases.
(If the value was already in the hash table at the beginning of
the call the the correct value would be returned, but if the
function had to parse to reach it then it would return NULL.)

This was tripping up the recently-added code to ignore messages
with NULL From:, Subject:, and To: headers, (which is fortunate
since otherwise the broken parsing might have stayed hidden for
longer).

notmuch: Revamp help message a bit.

The big update here is the addition of the dump and restore commands
which are next on my list. Also, I've now come up with a syntax for
documenting the arguments of sub-commands.

notmuch: Ignore files that don't look like email messages.

This is helpful for things like indexes that other mail programs
may have left around. It also means we can make the initial
instructions much easier, (the user need not worry about moving
away auxiliary files from some other email program).

Protect definition of _GNU_SOURCE.

I was getting a duplicate definition of this from somewhere, so
getting compiler warnings without this protection.

Remove test programs, xapian-dump and notmuch-index-message

These were just little tests while getting comfortable with
GMime and xapian. I'll likely use pieces of these as notmuch
continues, but for now let's not distract anyone looking
at notmuch with these.

And the code will live on in the history if I need to look
at it.

notmuch: Reword the progress report slightly.

I noticed this style during a recent Debian install and I liked
how much less busy it is compared to what we had before, (while
still telling the user everything she might want).

Rework message parsing to use getline rather than mmap.

The line-based parsing can be a bit awkward when wanting to peek
ahead, (say, for folded header values), but it's so convenient
to be able to trust that a string terminator exists on every
line so it cleans up the code considerably.

Don't hash headers we won't end up using.

Just saving a little work here.

Document which pieces of glib we're still using.

Looks like we can copy in a hash-table implementation, (from cairo,
say), and then a few _ascii_ functions from glib, (we'll need to
switch a few current uses if things like isspace, etc. to locale-
independent versions as well). So not too hard to free ourselves
of glib for now, (until we add GMime back in later, of course).

Hook up our fancy new notmuch_parse_date function.

With all the de-glib-ification out of the way, we can now use it
to allow for date-based sorting of Xapian search results.

notmuch_parse_date: Handle a NULL date string gracefully.

The obvious thing to do is to treat a missing date as the beginning
of time. Also, remove a useless cast from another return of 0.

date.c: Rename function to notmuch_parse_date

Now completing the process of making this function "our own".

The documentation is deleted here, because we already have
the documentation we want in notmuch-private.h.

date.c: Add hard-coded definition of HAVE_TIMEZONE

The original code expected this to be set by running configure.
We'll just manually set it here for now. This isn't as portable
as if we were doing some compile-time examination of the current
system, but I don't need portability now.

When someone comes along that wants to port notmuch to another
system, they will already have all the #ifdefs in place and
will simply need to add the appropriate machinery to set the
defines.

date.c: Don't use glib's slice allocator.

This change is gratuitous. For now, notmuch is still linking
against glib, so I don't have any requirement to remove this,
(unlike the last few changes where good taste really did
require the changes).

The motivation here is two-fold:

1. I'm considering switching away from all glib-based allocation
soon so that I can more easily verify that the memory management
is solid. I want valgrind to say "no leaks are possible" not
"there is tons of memory still allocated, but probably reachable
so who knows if there are leaks or not?". And glib seems to make
that impossible.

2. I don't think there's anything performance-sensitive about the
allocation here. (In fact, if there is, then the right answer
would be to do this parsing without any allocation whatsoever.)

date.c: Remove occurrences of gboolean.

While this is surely one of the most innocent typedefs, it still
annoys me to have basic types like 'int' re-defined like this.
It just makes it harder to copy the code between projects, with
very little benefit in readability.

For readability, predicate functions and variables should be
obviously Boolean-natured by their actual *names*.

date.c: Remove all occurrences of g_return_val_if_fail

That's got to be one of the hardest macro names to read, ever,
(it's phrased with an implicit negative in the condition,
rather than something simple like "assert").

Plus, it's evil, since it's a macro with a return in it.

And finally, it's actually *longer* than just typing "if"
and "return". So what's the point of this ugly idiom?

date.c: Keep the comments clean.

Never know when the children might be reading over my shoulder,
for example. :-)

date.c: Change headers/defines t owork within notmuch.

We can't rely on any gmime-internal headers, (and fortunately we
don't need to). We also aren't burdened with any autconf machinery
so don't reference any of that.

date.c: Remove a bunch of undesired code.

We're only interested in the date-parsing code here.

date.c: Convert from LGPL-2+ to GPL-3+

As authorized by LGPL-2 term (3).

date.c: Add new file directly from gmime2.4-2.4.6/gmime/gmime-utils.c

We're sucking in one gmime implementation file just to get the
piece that parses an RFC 822 date, because I don't want to go
through the pain of replicating that.

notmuch: Switch from gmime to custom, ad-hoc parsing of headers.

Since we're currently just trying to stitch together In-Reply-To
and References headers we don't need that much sophistication.
It's when we later add full-text searching that GMime will be
useful.

So for now, even though my own code here is surely very buggy
compared to GMime it's also a lot faster. And speed is what
we're after for the initial index creation.

notmuch: Ignore .notmuch when counting files.

We were correctly ignoring this when adding files, but not when
doing the initial count. Clearly we need better code sharing
here.

notmuch: Start actually adding messages to the index.

This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).

The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).

The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.)  We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).

The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.

xapian-dump: Rewrite to generate C code as output.

This was for some time testing, (to see how fast xapian could be
if we were strictly adding documents and not doing any other IO
or computation). The answer is that xapian is quite fast, (on
the order of 1000 documents per second).

Start a new top-level executable: notmuch.

Of course, there's not much that this program does yet. It's got
some structure for some sub-commands that don't do anything. And
it has a main command that prints some explanatory text and then
counts all the regular files in your mail archive.

Fix more memory leaks.

These were more significant than the previous leak because these were
in the loop and leaking memory for every message being parsed. It
turns out that g_hash_table_new should probably be named
g_hash_table_new_and_leak_memory_please. The actually useful function
is g_hash_table_new_full which lets us pass a free function, (to free
keys when inserting duplicates into the hash table). And after all,
weeding out duplicates is the only reason we are using this hash table
in the first place.

It almost goes without saying, valgrind found these leaks.

Fix a one-time memory leak.

This was a single object in main outside any loops, so there was
no impact on performance or anything, but obviously we still want
to patch this.

Of course, valgrind gets the credit for seeing this.

Avoid reading a byte just before our allocated buffer.

When looking for a trailing ':' to introduce a quotation we peek at
the last character before a newline. But for blank lines, that's not
where we want to look. And when the first line in our buffer is a
blank line, we're underrunning our buffer. The fix is easy---just
bail early on blank lines since they have no terms anyway.

Thanks to valgrind for pointing out this error.

Generate random thread IDs instead of using an arbitrary Message-ID.

Previously, we used as the thread-id the message-id of the first
message in the thread that we happened to find. In fact, this is a
totally arbitrary identifier, so it might as well be random. And an
advantage of actually using a random identifier is that we now have
fixed-length thead identifiers, (and the way is open to even allow
abbreviated identifiers like git does---though we're less likely to
show these identifiers to actual users).

Change progress report to show "instantaneous" rate. Also print total time.

Instead of always showing the overall rate, we wait until the end
to show that. Then, on incremental updates we show the rate over the
last increment. This makes it much easier to actually watch what's
happening, (and it's easy to see the efect of xapian's internal
10,000 document flush).

Protect against missing message id while indexing files

Walk address groups and parse each address separately

Signed-off-by: Keith Packard <keithp@keithp.com>

Reduce the verbosity of the progress indicator.

It's fast enough that we can wait for 1000 messages before updating.

Add support for message-part mime parts.

We could (and probably should) reparse and index all the headers from
the embedded message, but I'm not choosing to do that now---I'm just
indexing the body of the embedded message.

Avoid segfault on message with no subject.

It's fun how turning a program loose on 500,000 messages will find
lots of littel corner cases.

Add some sort of progress indicator.

It's nice to let the user know that something is happening.

Avoid complaints about messages with empty mime parts.

Avoid complaints about empty address lists.

Document the little details separating the sup and notmuch indexes.

As can be seen here, there are not a lot of differences. I've verified
this by using sup-sync to import a month of mail from the sup mailing
list, and comparing the database term-by-term, value-by-value, and
data-by-data with that created by notmuch. There are no differences
other than those documented here.

Avoid trimming initial whitespace while looking for signatures.

I ran into a message with an indented stack trace that my indexer
was mistaking for a signature.

Index an attachment's filename extension as well.

I hadn't realized that sup used a special term for this. But there
you go.

Index the filename of any attachment.

[sup-compat] Don't index mime parts with content-disposition of attachment

Here's another change which I'm making for sup compatibility against
my better judgment. It seems that sup never indexes content from
mime parts with content-disposition of attachment. But these
attachments are often very indexable, (for example, the first one
I encountered was a small shell script).

So I'll have to think a bit about whether or not I want to revert
this commit. To do this properly we would really want to distinguish
between attachments that are indexable, (such as text), and those
that aren't, (such as binaries). I know the mime-type alone isn't
alwas sufficient here as even this little plaintext shell script
was attached as octet-stream.

And if we wanted to get really fancy we could run things like antiword
to generate text from non-text attachments and index their output.

Add label "attachment" when an attachment is seen.

Split thread_id value on commas before inserting into hash.

One thread_id value may have multiple thread IDs in it so we need
to separate them out before inserting into our hash.

Add missing null terminator before using byte-array contents as string.

Thanks to valgrind for spotting this one.

notmuch-index-message: Add explicit support for multipart mime.

Instead of using the recursive "foreach" method, we implement our
own recursive function. This allows us to ignore the signature
component of a multipart/signed message, (which we certainly
don't need to index).

[sup-compat] Don't trim trailing whitespace on line introducing quotation.

Ignoring this whitespace seems like a good idea to me, but it's
interfering with my comparisons with sup since sup doesn't do this.

This might be a commit worth dropping in the future since it exists
only for pedantic consistency with sup and not for any reason of its
own.

notmuch-index-message: Fix handling of thread_id terms.

We now emit one term per thread_id, rather than the comma-separated
super-term we were doing previously.

notmuch-index-message: Use local-part of email addres in lieu of name.

If there's no name given, take the portion of the email addres
before the '@' sign.

One step closer to matching sup's terms in the database.

Use gmime's own reference-parsing code.

Here's another instance where I "knew" gmime must have support for
some functionality, but not finding it, I rolled my own. Now that
I found g_mime_references_decode I'm glad to drop my ugly code.

notmuch-index-message: Correctly parse and index encoded mime parts.

This cleans up some old code that was very ugly, (separately opening
the mail file and seeking to the end of the headers to parse the
body). I knew gmime must have had support for transparently decoding
mime content, but I just couldn't find it previously.

Note: Multipart and MultipartSigned parts are not handled yet.

Things are quite happy now. The few differences I see with sup are:

1. sup forces email address domains to lowercase, (I don't think I care)

2. sup and notmuch disagree on ordering of multiple thread_id values
   (another thing that's of no concern)

We are still doing one thing wrong when a message belongs to multiple
threads. We've got a nice comma-separated thread-value just like sup,
but then we're also putting in a comma-separated thread-term where
sup does multiple thread terms. That should be an easy fix.

Beyond that, sup and notmuch are still disagreeing on the term lists
for some messages, (I think attachment vs. inline content-disposition
is at least one piece of this). But there are likley still differences
in the heuristics for which chunks of the message body to index. I'll
be looking into this more.

notmuch-index-message: Lookup children for thread_id as well.

This provides the thread_id linkage for when a child message is
indexed before the parent.

notmuch-index-message: Use more meaningful variable names.

The abuse of the generic "value" name was getting very hard to read.

notmuch-index-message: Start generating correct thread_id values.

Currently we're looking up all parents (based on In-reply-to and
References header) and using the list of all thread_id values
from those as our thread_id value. We're missing one step which
sup does which is to also look up any children in the database
that have reference our message ID. So we'll need to do that next.

Factor out parsing of reference-header values and pickup In-reply-to.

This is in preparation for doing a couple of passes over the references,
(one to add terms to the database, and a second to find the thread_id).

We also now parse the In-reply-to header which we were missing before.
We treat it identically to the References header.

notmuch-index-message: Ignore more signature patterns.

Getting more sup-compatible all the time.

notmuch-index-message: Avoid crashing when a message has no references.

It's obviously an innocent-enough message, and the right thing is
so easy to do.

notmuch-index-message: Read message filenames from stdin

This allows for indexing an arbitrary number of messages with a
single invocation rather than just a single message on the command
line.

Move index_file out from main() into its own function.

This is a step toward having a program that will index many messages
with a single invocation.

notmuch-index-message: Index References as well.

We're basically matching sup now! (As long as one uses sup with my
special notmuch_index.rb file).

Minor code re-ordering for clarity.

Pull the "constant" source_id value out from among several calls
that set a value based on the Message ID.

notmuch-index-message: Don't index the "re:" prefix in subjects.

Getting closer to sup results all the time.

notmuch-index-message: Don't index the line introducing a quote.

We identify it based on a trailing ':' on the line before a quote
begins.

At this point the database-dump diff between sup and notmuch is
getting very, very small, (at least for our one test message).

notmuch-index-message: Don't index quoted lines and signatures.

At this point, we're achieving a result that is *very* close to
what sup does. The only difference is that we are still indexing
the "excerpts from message ..." line, and we are not yet indexing
references.

notmuch-index-message: Separate gen_terms_body into its own function

This one is complex enough to deserve its own treament.

notmuch-index-message: Add code to actually create a Xapian index

Most of this code is fairly clean and works well. One part is
fairly painful---namely extracting the body of an email message
from libgmime. Currently, I'm just extracting the offset to
the end of the headers, and then separately opening the message.
Surely there's a better way.

Anyway, with that the results are looking very similar to sup-sync
now, (as verified by xapian-dump). The only substantial difference
I'm seeing now is that sup does not seem to index quoted portions
of messages nor signatures. I'm not actually sure whether I want
to follow sup's lead in that or not.

Rename g_mime_test to notmuch-index-message

In preparation for actually creating a Xapian index from the
message, (not that we're doing that quite yet).

xapian-dump: Add a little mor indentation

Just to make it easier to visually identify where one document ends
and the next begins.

Include document data in the dump.

At the same time, I've started hacking up sup with a new NotmuchIndex
class in the place of the previous XapianIndex class. The new class
stores only the source_info field in the document data, (rather than
a serialized ruby hash with a bunch of data that can be found in the
original message).

Eventually, I plan to replace source_info with a relative filename for
the message, (or even a list of filenames for when multiple messages
in the database share a common message ID).

xapian-dump: Add support to unserialize values.

The interface for this is cheesy, (bare integer value numbers on the
command line indicating that unserialization is desired for those
value numbers). But this at least lets us print sup databases with
human-readable output for the date values.

Add .gitignore file to ignore compiled binaries.

xapian-dump: Add values to the dump as well.

xapian-dump: Fix to dump all terms for each document ID.

xapian-dump: Actually dump document IDs

It's not a complete tool yet, but it at least does something now.

Remove unused variable.

Compiling with -Wall considered useful.

Add the beginnings of a xapian-dump program.

This will (when it is finished) make a much more reliable way to
ensure that notmuch's sync program behaves identically to sup-sync.
It doesn't actually do anything yet.

Add sup-compatible prefixes and achieve sup-compatible print output

What I've done here is to instrument sup-sync to print the text
and terms objects it constructs just before indexing a message.
Then I've made my g_mime_test program achieve (nearly) identical
output for an example email message, (just missing the body
text). Next we can start shoving this data into a Xapian index.

Initial commit of a test program to form the basis of notmuch.

Basically just playing with some simple code using libgmime to parse
an email message.