| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
|
| |
Replacing them with calls to talloc_asprintf if possible, otherwise
to asprintf (with it's painful error-handling leaving the pointer
undefined).
|
| |
|
|
|
| |
And augment "notmuch search" to print tag values as well as thread ID
values. This tool is almost usable now.
|
| |
|
|
|
|
|
| |
We want to be able to iterate over tags stored in various ways, so
the previous TermIterator-based tags object just wasn't general
enough. The new interface is nice and simple, and involves only
C datatypes.
|
| |
|
|
|
| |
Apparently, I didn't copy enough of the "notmuch dump" implementation
since it didn't have a similar leak.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've now got a new notmuch_query_search_threads and a
notmuch_threads_result_t iterator. The thread object itself
doesn't do much yet, (just allows one to get the thread_id),
but that's at least enough to see that "notmuch search" is
actually doing something now, (since it has been converted
to print thread IDs instead of message IDs).
And maybe that's all we need. Getting the messages belonging
to a thread is as simple as a notmuch_query_search_messages
with a string of "thread:<thread-id>".
Though it would be convenient to add notmuch_thread_get_messages
which could use the existing notmuch_message_results_t iterator.
Now we just need an implementation of "notmuch show" and we'll
have something somewhat usable.
|
| |
|
|
|
|
|
|
|
|
| |
Along with renaming notmuch_results_t to notmuch_message_results_t.
The new type is quite a mouthful, but I don't expect it to be
used much other than the for-loop idiom in the documentation,
(which does at least fit nicely within 80 columns).
This is all in preparation for the addition of a new
notmuch_query_search_threads of course.
|
| |
|
|
|
|
| |
Having to enumerate all the enum values at every switch is annoying,
but this warning actually found a bug, (missing support for
NOTMUCH_STATUS_OUT_OF_MEMORY in notmuch_status_to_string).
|
| |
|
|
| |
Wow, lots of missing 'static' on internal functions.
|
| |
|
|
|
| |
It's easy enough to squelch the warning with an __attribute__ ((unused))
and it might just catch something for us in the future.
|
| |
|
|
|
|
|
|
| |
When adding -Wextra we also add -Wno-ununsed-parameters since that
function means well enough, but is really annoying in practice.
So the warnings we fix here are basically all comparsions between
signed and unsigned values.
|
| |
|
|
|
|
| |
We were previously just doing fprintf;exit at each point, but I
wanted to add file and line-number details to all messages, so it
makes sense to use a single macro for that.
|
| |
|
|
| |
Little details can make big impressions.
|
| |
|
|
|
|
|
|
|
|
| |
The "notmuch setup" output was getting overwhelmingly verbose.
Also, some people might not have a lot of mail, so might never need
this optimization. It's much better to move the hint to the time
when the user could actually benefit from it, (it's easy to detect
that "notmuch new" took more than 1 second, and we know if there
are any read-only directories there or not).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This isn't behaving at all like it's documented yet, (for example,
it's returning message IDs not thread IDs[*]). In fact, the output
code is just a copy of the body of "notmuch dump", so all you
get for now is message ID and tags.
But this should at least be enough to start exercising the query
functionality, (which is currently very buggy).
[*] I'll want to convert the databse to store thread documents
before fixing that.
|
| |
|
|
|
|
|
|
|
|
| |
With some recent testing, the timestamp was failing, (overflowing
the term limit), and reporting an error, but the top-level notmuch
command was still returning a success return value.
I think it's high time to add a test suite, (and the code base is
small enough that if we add it now it shouldn't be *too* hard to
shoot for a very high coverage percentage).
|
| |
|
|
|
|
|
| |
This reverts commit fb1bae07002d45138832eacb280419dbd7a19774.
These initializers were totally necessary. I clearly wasn't
thinking straight when I removed them.
|
| |
|
|
| |
It gets annoying pretty quick.
|
| |
|
|
|
|
| |
With this, "notmuch new" is now plenty fast even with large archives
spanning many sub-directories. Document this both in "notmuch help"
and also in the output of notmuch setup.
|
| |
|
|
|
| |
There's no need to stat each directory both before and after each
recursive call.
|
| |
|
|
|
| |
It definitely doesn't help that we have the same messages in both
"setup" and "new". Should combine those really.
|
| |
|
|
|
| |
Printing "Added 1 new messages" just looks like lack of attention
to detail, (but yes plurals can be annoying this way).
|
| |
|
|
| |
It's nice to have a tool that at least construct actual sentences.
|
| |
|
|
|
|
|
|
| |
Finally, I can get new messages into my notmuch database without
having to run a complete "notmuch setup" again. This takes
advantage of the recent timestamp capabilities in the database
to avoid looking into directories that haven't changed since the
last time "notmuch new" was run.
|
| |
|
|
|
| |
Also change to use goto rather than early returns. And once again,
there were lots of bugs in the error cases previously.
|
| |
|
|
|
|
|
|
|
|
| |
Get rid of a useless leading 0 on the seconds value, and make a
distinction between "files" and "messages", (we process many
files, but not all of them are recongized as messages). Finally,
add a summary line at the end saying how many unique messages
were added to the database. Since this comes right after the
total number of files, it gives the user at least a hint as
to how many messages were encountered with duplicate message IDs.
|
| |
|
|
|
|
|
|
|
|
| |
Some people might argue for more initializers to be "safer",
but I actually prefer to leave things this way. It saves
typing, but the real benefit is that the things that do
require initialization stand out so we know to watch them
carefully. And with valgrind, we actually get to catch
errors earlier if we *don't* initialize them. So that can
be "safer" ironically enough.
|
| |
|
|
|
| |
We had early returns instead of goto statments, and sure enough,
they were leaking. Much cleaner this way.
|
| |
|
|
|
| |
These will be very helpful to implement an efficient "notmuch new"
command which imports new mail messages that have appeared.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This helps the user gauge the severity of the error.
For example, when restoring my sup tags I see a bunch of tags missing
for message IDs of the form "sup-faked-...". That's not surprising
since I know that sup generates these with the md5sum of the message
header while notmuch uses the sha-1 of the entire message. But how
much will this hurt?
Well, now that I can see that most of the missing tags are just
"attachment", then I'm not concerned, (I'll be automatically creating
that tag in the future based on the message contents). But if a
missing tag is "inbox" then that's more concerning because that's data
that I can't easily regenerate outside of sup.
|
| |
|
|
|
| |
Be kind and let the user print error messages, not just error
codes.
|
| |
|
|
|
|
| |
It's pretty easy to do with all the right infrastructure in place.
Now that I can get my tags from sup to notmuch, maybe I'll be able
to start reading mail again.
|
| |
|
|
|
| |
We'll want this same thing with "notmuch restore", (and really
anything using getline).
|
| |
|
|
| |
Simple little bug here made all the tags run together.
|
| |
|
|
| |
Just a little bug I noticed while editing nearby code.
|
| |
|
|
|
|
|
|
|
|
| |
This is to help keep the report looking clean when a new report
is shorter than a previous reports, (say, when crossing the
boundary from over one minute remaining to less than one minute
remaining).
This used to be here, but I must have accidentally dropped it
when reformatting the progress report recently.
|
| |
|
|
|
|
|
| |
Using the address of a static char* was clever, but really
unnecessary. An empty string is much less magic, and even
easier to understand as the way to query everything from
the database.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously we were leaking[*] memory in that the memory footprint of
a "notmuch dump" run would continue to grow until the output was
complete, and then finally all the memory would be freed.
Now, the memory footprint is small and constant, O(1) rather than
O(n) in the number of messages.
[*] Not leaking in a valgrind sense---every byte was still carefully
being accounted for and freed eventually.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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").
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Less reliance on glib is always nice for our memory-leak testing
efforts.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
| |
We were correctly ignoring this when adding files, but not when
doing the initial count. Clearly we need better code sharing
here.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
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.
|
Carl Worth