| Age | Commit message (Collapse) | Author |
|---|
|
This was just some extra noise printed when requesting a non-default
mail directory itneractively.
|
|
I recently added a print of the subject line for use as part of a
two-line summary in the emacs client. But of course, the subject was
already being printed on the next line. So I didn't really need to add
anything, I could have just stopped hiding what was already
printed. Anyway, we now avoid printing it twice in a row.
|
|
And change the display code in emacs to display the one-line summary
in inverse video.
|
|
It would be nice to have this documentation live in a single place,
but for now, this is what we get.
|
|
I've been using these for a long time, but I had neglected to document
them until now.
|
|
The more general command is more consistent, and more useful.
We also fix "notmuch search" to output copy-and-pasteable search terms
for the thread with "thread:" prepended already. Similarly, the
message-ID in the output of "notmuch show" is also now printed as a
valid search term, ("id:<message-id>" rather than "ID: <message-id>").
Naturally, the emacs code is also changed to track these changes.
|
|
This will allow a client using "notmuch show" to directly open the
filename and do whatever it wants with it.
|
|
We were inadvertently calling g_object_unref on a wild pointer leading
to the following error message:
GLib-GObject-CRITICAL **: g_object_unref: assertion
`G_IS_OBJECT (object)' failed
Now, why glib doesn't abort on critical errors, I'll never understand.
|
|
I previously had a hack that special-cased the "unread" tag and
printed it on the same line as the message ID. But now that we are
printing all tags at the end of the one-line summary we don't need
this anymore. Get rid of it, and just read "unread" from the list of
tags just like any other tag.
|
|
This is in the one-line summary so should always be visible even
in our emacs client that's so eager to make things invisible.
|
|
Also hide all markers.
From here, all we really need for legibility is the following:
* Hide away citations and signatures
* Call out the one-line summary some way, (larger font size?)
* Add nesting for replies
|
|
We were previously using things like "%message{" which were not
guaranteed to never appear in an email message. Using a control
character (^L or '\f' instead of '%') gives us better assurance that
our delimiter doesn't show up in an original email message.
This still isn't entirely safe since we're decoding encoded text in
the body of the email message so almost all bets are off really.
|
|
Most all of the returned strings will now fill most of a 12-character
string, (depending on the length of the month).
|
|
Additionally, print a part number for each MIME part so that the
client could (conceivably) ask for the contents of a specific
part by part number.
|
|
This can allow for the client to hide undesired MIME parts
such as text/html.
|
|
We now actually get text content rather than blocks of BASE64, etc.
|
|
By pulling content out of notmuch help, and also the messages
printed by "notmuch setup".
|
|
I had noticed several times earlier that having a talloc context
passed in would make things more convenient. I'm not exercising
that convenience yet, but the context is there now, (and there's
one fewer item on our TODO list).
|
|
Shorter naming without being any less clear. A definite win.
|
|
The shorter output is much nicer for something that might end up
in an emacs mini-buffer, for example.
|
|
We were aware of this bug when we wrote the function, (that a date
six days in the past would be treated as the "Friday" or as the
"Oct. 23" case depending on whether its time was before or after
the current time today). We thought it wouldn't be a problem, but
in practice it is. In scanning search results with this output,
the transition between formats makes it look like a day boundary,
(so it would be easy to mistakenly think "Oct. 23" is Thursday).
Fix this to avoid confusion, (still being careful to never print
"Thursday" for a date 7 days in the past when today is Thursday).
|
|
The new function for formatting relative dates is nice enough that
we need to start using it more places. Here's one of them.
|
|
The idea here is that a client could usefully display just this one
line while optionally hiding the other header fields.
|
|
This is for now a non-configurable list of Subject, From, To, Cc,
Bcc, and Date.
|
|
This is just the raw message body for now, (so any MIME parsing will
be up to the consumer). And this will likely change in the future.
|
|
We're using a delimiter syntax that Keith is optimistic about
being able to easily parse in emacs. Note: We're not escaping
any occurrence of the delimiters in the message yet, so we'll
need to fix that.
|
|
We now store only a relative path inside the database so the database
is not nicely relocatable.
|
|
With the recent addition of full-text indexing, printing only once per
1000 files just isn't often enough. The new timer-based approach will
be reliable regardless of the speed of adding message.
|
|
The original documentation of implicit AND is what we want, but
Xapian doesn't actually let us get that today. So be honest about
what the user can actually expect. And let's hope the Xapian
wizards give us the feature we want soon:
http://trac.xapian.org/ticket/402
|
|
The big addition here is the first description of the syntax for
the query strings for "notmuch search", (and, by reference, for
"notmuch tag").
|
|
Putting all of our documentation into a single help message was getting
a bit unwieldy. Now, the simple output of "notmuch help" is a reasonable
reminder and a quick reference. Then we now support a new syntax of:
"notmuch help <command>" for the more detailed help messages.
This gives us freedom to put more detailed caveats, etc. into some
sub-commands without worrying about the usage statement getting too
long.
|
|
This uses the same search functionality as "notmuch search" so
it should be quite powerful. And this global search might be
quick enough to be used for "automatic" adding of tags to new
messages.
Of course, this will all be a lot more useful when we can search
for actual text of messages and not just tags.
|
|
I'm trying to stick to a habit of fixing previously-introduced bugs
on side branches off of the commit that introduced the bug. The
idea here is to make it easy to find the commits to cherry pick
if bisecting in the future lands on one of the broken commits.
|
|
We were incorrectly only destroying messages in the case of
successful addition to the database, and not in other cases,
(such as failure due to FILE_NOT_EMAIL).
I'm still not entirely sure why this was performing abysmally, (as in
making an operation that should take a small fraction of a second take
10 seconds), nor why it was causing the database to entirely fail to
get new results.
But fortunately, this all seems to work now.
|
|
The recent addition of support for automatically adding tags to
new messages for "notmuch new" caused "notmuch setup" to segfault.
The fix is simple, (just need to move a destroy function to inside
a nearby if block).
Did I mention recently we need to add a test suite?
|
|
This means that the restore operation will now properly pick up the
removal of tags indicated by the tag just not being present in the
dump file.
We added a few new public functions in order to support this:
notmuch_message_freeze
notmuch_message_remove_all_tags
notmuch_message_thaw
|
|
The code was just a little messy here with three parallel conditions
testing for message == NULL.
|
|
We use this to implement the addition of "inbox" and "unread" tags
for all messages added by "notmuch new".
|
|
Somehow this naming with an underscore crept in, (but only in the
private header, so notmuch.c was compiling with no prototype). Fix
to be the notmuch_thread_get_subject originally intended.
|
|
And use this in "notmuch search" to display subject line as well as
thread ID.
|
|
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.
|
