I was confusing myself with some rules installing to directories and
some installing to files. We do still install to a filename when
simultaneously renaming, (such as notmuch-completion.bash to notmuch).
When this function was originally written, the 'message' object was
always destroyed locally, so I thought it would be good to use a NULL
talloc context to make it more obvious if there was any leak.
Since then, however, this function has been changed to optionally
return the added message, and in that case we *don't* free the message
locally, so let's let the database be the talloc context.
The documentation for 'next-line' suggests that 'forward-line' is a
better choice for non-interactive usage. That appears to be the case
here; using next-line caused emacs to spin forever for me.
Signed-off-by: Keith Packard <keithp@keithp.com>
This is the default separator used by mailman, so there's a lot of
clutter in thread displays without this. Also, we not provide a nice
variable to the user (notmuch-show-signature-regexp) for configuring
this.
I think there's a GMime bug that we're getting parts decoded without a
final newline (the encoded parts seem to have them just fine). We can
workaround the bug easily enough by finding a part-closing delimiter
that is not at the beginning of a line, and if so, just insert a
newline.
Without this, the one-line-summary of the next message would continue
on the same line as the last line of the previous message, (and this
would often happen for mailing-list messages where mailman would add
an extra part for its signature block).
notmuch restore used to only add tags; now that it clears existing
tags, it needs to operate on messages even if the new tag list is empty.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Carl Worth <cworth@cworth.org>:
I fixed up the indentation here, (someday we might switch to 8-space
indents, but we haven't yet).
This makes it much easier to actually read the subject lines.
The user can set notmuch-search-authors-width to control the width of
the column.
Two possible ideas for improving this support further:
1. Make the excess authors invisible instead of removing them from
the buffer, (which means that isearch could still find them).
2. Have the user variable control a percentage of the window width
rather than being a fixed number of columns.
Now that we're actually adding text to the buffer for the indentation,
our old aproach of using positions to record regions to manipulate is
now longer correct. Fortunately, it's easy to switch from positions to
markers which are robust, (just call point-marker instead of point and
all relevant functions accept markers as well as points).
I also finally fixed the bug where the text "[6 line signature]" we
display was causing the one-line-summary of the next message to be on
its same line rather than at the beginning of the next line where it
belongs.
We now properly analyze the in-reply-to headers to create a proper
tree representing the actual thread and present the messages in this
correct thread order. Also, there's a new "depth:" value added to the
"message{" header so that clients can format the thread as desired,
(such as by indenting replies).
It's funny that I picked up the habit of always including a space
before a left parenthesis from Keith, and now he's in the habit of
contributing code without it.
The existing notmuch_message_get_header is *almost* good enough for
this, except that we also need to remove the '<' and '>'
delimiters. We'll probably want to implement this function with
database storage in the future rather than loading the email message.
This prototype has been sitting around for a while with no function
implementing it. I wonder if there's a compiler warning I could turn
on to catch these things.
Previously, the notmuch_messages_t object was a linked list built on
top of a linked-list node with the odd name of notmuch_message_list_t.
Now, we've got much more sane naming with notmuch_message_list_t being
a list built on a linked-list node named notmuch_message_node_t. And
now the public notmuch_messages_t object is a separate iterator based
on notmuch_message_node_t. This means the interfaces for the new
notmuch_message_list_t object are now made available to the library
internals.
The new object is simply a linked-list of notmuch_message_t objects,
(unlike the old object which contained a couple of Xapian iterators).
This works now by the query code immediately iterator over all results
and creating notmuch_message_t objects for them, (rather than waiting
to create the objects until the notmuch_messages_get call as we did
earlier).
The point of this change is to allow other instances of lists of
messages, (such as in notmuch_thread_t), that are not directly related
to Xapian search results.
Previously, an excess call would have caused a crash. Now it simply
does nothing. Also, make notmuch_tags_get use a similar, consistent
early return for a NULL iterator.
Currently just supports viewing all MIME parts in the message. There's
not yet support for selecting and viewing individual parts, but that
should be easy to add from here, (now that we've found
mm-display-parts to do all the heavy lifting).
There are still open questions about how to correctly compute the
intended list of recipients. We'll probably need separate "reply to
sender" and "reply to all" commands at some point (unfortunately).
By installing a signal handler for SIGINT we can ensure that no work
that is already complete will be lost if the user interrupts a
"notmuch new" run with Control-C.
We were properly sorting the threads based only on matched messages,
but we were displaying the date based on the total messages in the
thread, which led to inconsistent and very confusing results.
This gives us two different default search orders: The inbox view that
comes up from "M-x notmuch" is sorted in chronological order (oldest
threads first). A new global search "M-x notmuch-search" will instead
be in reverse chronological order (newest threads first).
Any filtered searches retain the sort order of the search being
filtered.
There's not yet any interface for changing the sort order of a search
after it is constructed.
Note that the difference between thread results in date order and
thread results in reverse-date order is not simply a matter of
reversing the final results. When sorting in date order, the threads
are sorted by the oldest message in the thread. When sorting in
reverse-date order, the threads are sorted by the newest message in
the thread.
This difference means that we might want an explicit option in the
interface to reverse the order, (even though the default will be to
display the inbox in date order and global searches in reverse-date
order).
Otherwise, things in the lib sub-directory weren't getting recompiled
even when lib/notmuch.h was changed.
The original rule we were using came from the GNU Makefile manual, but
only handled files in the current directory, not file in
sub-directories as we use here with our non-recursive Makefile.
So the .deps files being created were being put in the right place,
(such as .deps/lib/database.d), but the compiler was generating a
dependency for "database.o" rather than "lib/database.o" like we
want. We were already trying to do a sed job on that name to add a
dependency for the .d file as well. But the sed job was failing since
the expected pattern wasn't there, (the directory name was missing).
So the fix is simply to use basename to construct the search pattern,
and then use the name with the directory in the replacement (rather
than the back-reference).
Note that we don't print the number of *unread* messages, but instead
the number of messages that matched the search terms. This is in
keeping with our philosophy that the inbox is nothing more than a
search view. If we search for messages with an inbox tag, then that's
what we'll get a count of. (And if somebody does want to see unread
counts, then they can search for the "unread" tag.)
Getting the number of matched messages is really nice when doing
historical searches. For example in a search like:
notmuch search tag:sent
(where the "sent" tag has been applied to all messages originating
from the user's email address)---here it's really nice to be able to
see a thread where the user just mentioned one point [1/13] vs. really
getting involved in the discussion [10/29].
We add a hash to the thread object so that we can detect author names
that have already been added to the list, and avoid adding them
redundantly. This avoids the giant chain of "bugzilla-daemon,
bugzilla-daemon, bugzilla-daemon, bugzilla-daemon, ..." author lists
that we would get otherwise, for example.
We've now expanded the notmuch_thread_create function to fire off a
secondary database query to find all the messages that belong to this
particular thread. This allows us to now have the complete authors'
list for the thread, and will also make it trivial to print accurate
message counts for threads in the future.
This time, things are actually tested. The current results aren't
exactly the same as previous results since the incremental search
doesn't necessarily see all the new messages that pertain to the
thread. This means that some author names are missing.
I plan to fix this by doing an additional database search for all
messages in each thread. Of course, this will also be different than
before since now the result will display *all* authors in the thread
(rather than only those that matched the search) but that's probably
what we really want to display anyway.
I thought it would be safe enough to return a few extra threads,
(since we happened to already get the relevant messages out of the
database). The problem is that then requires the caller to carefully
read the number of threads returned and adjust its next "first" value
accordingly. The interface is much simpler to use if we simply return
exactly what is asked for and no more.
This serves me right for committing untested code. The
notmuch_query_search_threads was totally broken, (it didn't properly
treat -1 as being unlimited and instead returned no threads in that
case).
The library interface now allows the caller to do incremental searches,
(such as one page of results at a time). Next we'll just need to hook
this up to "notmuch search" and the emacs interface.
I wrote these originally jsut for debugging. They've never been hooked
up to any keybinding and the existing "M-x visible-mode" does what's
needed anyway.
It's important to have the names present for determining whether a
thread is worth reading or not. We may want to think about
abbreviating the list somehow if it is excessively long (or redundant
as in bugzilla-daemon, bugzilla-daemon, bugzilla-daemon, etc.).
We never did export any interface to get at these, and when I went to
use these, I found them inadequate, (because I wanted to distinguish
address found in from: from those found in To:). Meanwhile, it was
easy enough to extract addresses with a search like:
notmuch show tag:sent | grep ^To:
so the storage of contact terms was just wasting space. Stop that.
This note was described in the previous commit message, but mistakenly
not committed:
The note about making "notmuch setup" faster is now rewritten to apply
to "notmuch new" since "notmuch setup" no longer does any mail
indexing.
