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.
We recently added support for "notmuch reply" and also made (most of)
the hidden components self documenting.
The note about making "notmuch setup" faster is now rewritten to apply
to "notmuch new" since "notmuch setup" no longer does any mail
indexing.
I recently discovered that mb2md has the annoying bug of creating
files with mtime of 0, and notmuch then promptly ignored them,
(thinking that its timestamps initialized to 0 were just as new).
We fix notmuch to not exclude messages based on a database timestamp
of 0.
Leaving this variable uninitialized caused notmuch to display a random
number while counting files for the new database.
Signed-off-by: Keith Packard <keithp@keithp.com>
This way we get to take advantage of the configuration of the user's
email addresses in notmuch, (rather than expecting the user to
configure all of their email addresses in message mode as well).
That is, if mail was addresses to one of the "other" addresses in the
configuration file, then the reply will have its "From" header set to
that same address rather than the primary address.
All of the following commands:
notmuch dump
notmuch reply
notmuch restore
notmuch search
notmuch show
notmuch tag
were calling notmuch_database_open with an argument of NULL. This was
a legitimate call until the recent addition of configuration, after
which it is expected that all commands will lookup the correct path in
the configuration file. So fix all these commands to do that.
Also, while touching all of these commands, we fix them to use the
talloc context that is passed in rather than creating a local talloc
context. We also switch from using goto for return values, to doing
direct returns as soon as an error is detected, (which can be leak
free thanks to talloc).
If this is run first, it will run "notmuch setup" directly. After that
is successful, it will look for a databae and tell the user to run
"notmuch new" if the database doesn't exist yet. Finally, if the
database is present, it will provide some example "notmuch search"
commands for the user to try.
It's quite possible for someone to read the documentation and run
"notmuch setup" rather than just "notmuch". In that case, we don't
want to be any less welcoming.
This will allow for things like the database path to be specified
without any cheesy NOTMUCH_BASE environment variable. It also will
allow "notmuch reply" to recognize the user's email address when
constructing a reply in order to do the right thing, (that is, to use
the user's address to which mail was sent as From:, and not to reply
to the user's own addresses).
With this change, the "notmuch setup" command is now strictly for
changing the configuration of notmuch. It no longer creates the
database, but instead instructs the user to call "notmuch new" to do
that.
The advantage here is that we actually get the necessary folding of
long headers, (particularly the References header, but also things
like Subject). This also gives us parsed recipient addresses so that
we can easily elide the sender's address(es) from the recipient list
(just as soon as we have a configured value for the recipient's
address(es)).
We were just starting to get "notmuch reply" into shape in order to
provide the needed functionality here, but then I realized that the
message-reply function built into emacs is already more functional,
(at least for the case of replying to a single message).
We know take the original From: and all recipients and put them on the
To: line. We also add a "Re: " to the subject, and we add In-Reply-To:
and References: headers.
Reviewed-by: Carl Worth <cworth@cworth.org>
Keith wrote all the code here against notmuch before notmuch.c was
split up into multiple files. So I've pushed the code around in
various ways to match the new code structure, but have generally tried
to avoid making any changes to the behavior of the code.
I did fix one bug---a missing call to g_mime_stream_file_set_owner in
show_part which would cause "notmuch show" to go off into the weeds
when trying to show multiple messages, (since the first stream would
fclose stdout).
Now that the client sources are alone here in their own directory,
(with all the library sources down inside the lib directory), we can
break the client up into multiple files without mixing the files up.
The hope is that these smaller files will be easier to manage and
maintain.
Previously, the top-level Makefile was explicitly adding -I./lib to
the compiler flags. However, that's something that's much better done
from within the Makefile.local fragment within the lib directory
itself.
We were previously using separate CFLAGS and NOTMUCH_CFLAGS variables
in an attempt to allow the user to specify CFLAGS on the command-line.
However, that's just a lot of extra noise in the Makefile when we can
instead let the user specify what is desired for CFLAGS and then use
an override to append the things we require. So our Makefile is much
neater now.
I saw this recommendation in the implementation notes for "Recursive
Make Considered Harmful" and then the further recommendation for
implementing the idea in the GNU make manual.
The idea is that if any of the files change then we need to regenerate
the dependency file before we regenerate any targets.
The approach from the GNU make manual is simpler in that it just uses
a sed script to fix up the output of an extra invocation of the
compiler, (as opposed to the approach in the implementation notes from
the paper's author which use a wrapper script for the compiler that's
always invoked rather than the compiler itself).
The idea here is that every Makefile at each lower level will be an
identical, tiny file that simply defers to a top-level make.
Meanwhile, the Makefile.local file at each level is a Makefile snippet
to be included at the top-level into a large, flat Makefile. As such,
it needs to define its rules with the entire relative directory to
each file, (typically in $(dir)). The local files can also append to
variables such as SRCS and CLEAN for files to be analyzed for
dependencies and to be cleaned.
Instead of the old name of Makefile.dep. The idea being that the
user really doesn't need to see this by default, (and if debugging
the Makefile, the rules will make the name obvious).
Previously, when selecting a thread to view from the search buffer, we
would advance the point by one line before showing the thread, (so
that it would be ready to show the next thread once the user was done
with the current thread). This was annoying when the user temporarily
exited the thread view, (because the "wrong" thread was then selected
in the search view).
We get a more consistent experience by waiting to advance until the
user has finished viewing one thread and is ready to view the next.
This crash was introduced sometime recently, as previously things
worked fine when notmuch detected that a file is not an email.
We're definitely overdue for that test suite.
A recent "notmuch restore" command took *forever* for me. Obviously,
we need to fix the underlying performance bug in Xapian, but in the
meantime, a progress indicator would help.
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.
I'd fixed this earlier when I had a private copy of GMime's
date-parsing code, but I lost the fix when I recently switched to
calling the GMime function.
The recent change of the hidden thread-ID syntax caused this message
to instead be replaced with a cryptic "search failed" error and an
internal regular expression. Put our nice message back.
