This new directory ojbect provides all the infrastructure needed to
detect when files or directories are deleted or renamed. There's still
code needed on top of this (within "notmuch new") to actually do that
detection.
This commit contains my changes to the API proposed by Keith. Nothing
is dramatically different. There are minor things like changing
notmuch_files_t to notmuch_filenames_t and then various things needed
for completeness as noticed while implementing this, (such as
notmuch_directory_destroy and notmuch_directory_set_mtime).
This will allow applications to support the removal of messages, (such
as when a file is deleted from the mail store). No removal support is
provided yet in commands such as "notmuch new".
The existing find_doc_ids function is convenient when the caller
doesn't want to be bothered constructing a term. But when the caller
*does* have the term already, that interface is just wasteful. So we
export a lower-level interface that maps a pre-constructed term to a
document-ID iterators.
The code to map a filename to a direntry is something that we're going
to want in a future _remove_message function, so put it in a new
function _notmuch_database_filename_to_direntry .
The library interface is unchanged so far, (still just
notmuch_database_add_message), but internally, the old
_set_filename function is now _add_filename instead.
Instead of storing the complete message filename in the data portion
of a mail document we now store a 'direntry' term that contains the
document ID of a directory document and also the basename of the
message filename within that directory. This will allow us to easily
store multple filenames for a single message, and will also allow us
to find mail documents for files that previously existed in a
directory but that have since been deleted.
Some pending commits want the _split_path functionality separate from
mapping a directory to a document ID. The split_path function now
returns the basename as well as the directory name.
We're planning to have mail documents refer to directory documents for
the path of the containing directory. To support this, we need the
path in the data, (since the path in the 'directory' term can be
irretrievable as it will be the SHA1 sum of the path for a very long
path).
We'll soon have mail documents referring to their parent directory's
directory documents, so we'll need access to _find_parent_id in files
such as message.cc.
Storing the document ID of the parent of each directory document will
allow us to find all child-directory documents for a given directory
document. We will need this in order to detect directories that have
been removed from the mail store, (though we aren't yet doing this).
The recent change from storing absolute paths to relative paths means
that new directory documents will already be created, (and the old
ones will just linger stale in the database). Given that, we might as
well put a clean name on the term in the new documents, (and no real
flag day is needed).
We were already storing relative mail filenames, so this is consistent
with that. Additionally, it means that directory documents remain
valid even if the database is relocated within its containing
filesystem.
We'll soon be having multiple entry points that accept a filename
path, so we want common code for getting a relative path from a
potentially absolute path.
This was really the last thing keeping the initial run of "notmuch
new" being different from all other runs. And I'm taking a fresh
look at the performance of "notmuch new" anyway, so I think we can
safely drop this optimization.
And fix the initialization such that the private enum will always have
distinct values from the public enum even if we similarly miss the
addition of a new public value in the future.
Several people complained that the humor wore thin very quickly. The
most significant case of "not much mail" is when counting the user's
initial mail collection. We've promised on the web page that no matter
how much mail the user has, notmuch will consider it to be "not much"
so let's say so. (This message was in place very early on, but was
inadvertently dropped at some point.)
The in-development version of Xapian provides a config program named
xapian-config-1.1 while the released version provides a program named
xapian-config instead. By default, we now try each of these in turn,
and we also allow the user to set a XAPIAN_CONFIG environment variable
to explicitly specify a particular program.
We've received a user report that the hidden citations were annoying
since the user couldn't tell what was being referred to by subsequent
text. Apparently it wasn't obvious enough that the hidden citation
could be revealed by clicking or by pressing Enter. So make the button
text say as much.
In the message mentioned in the previous commit, an ASCII diagram was
included in which '>' was used as the first non-whitespace character
in a line. Notmuch previously (and mistakenly) regarded this as a
citation.
We fix this by only regarding a '>' in the first column of an email as
introducing a citation.
Thanks to Dirk Hohndel for reporting the bug. The infinite loop was first
noticed in the following message (available from the Linux kernel mailing list):
alpine.LFD.2.00.0912081304070.3560@localhost.localdomain
Note that the bug does not show up when viewing the message in
isolation---the bug was triggered only when viewing this file indented
to a depth of at least 13.
The fix is simply to use a marker rather than an integer position when
recording a point we plan to move back to later, (since inserting the
indented button causes the buffer position of the desired marker to
change).
Previously only mime parts that indicated specified a "disposition" of
"attachment" were saved. However there are time when it is important
to be able to save inline content as well. After this commit any mime
part that specifies a filename will be considered when saving
attachments.
Similar to the way thread-viewing was broken after a thread was
archived, (and recently fixed), tag manipulation has also been broken
when the thread no longer matches the current search.
This also means that the behavior of '+' and '-' are now different
than that of '*'. The '+' and '-' bindings now return to the previous
behavior old affecting all messages in the thread, (and not simply
those matching the search).
I actually prefer this behavior, since otherwise a '-' operation on a
thread might not actually remove the tag from the thread, (since it
could operate on a subset of the thread and not hit all messages with
the given tag).
So I'd now like to fix '*' to be consistent with '+' and '-', for
which we add an item to TODO.
This fixes the annoying bug of archiving a thread, and then going back
to open it and getting an error. It needs the notmuch-show API
changing patch of 1259979997-31544-3-git-send-email-david@tethera.net.
Also modify the one call to notmuch-show in notmuch.el. This makes
the call (notmuch-show thread-id) will work when there is no binding
for notmuch-search-query-string; e.g. when called from user code
outside notmuch.
Add functions notmuch-search-find-authors and notmuch-find-subject to
match notmuch-find-thread-id. These functions are just a wrapper
around get-text-property, but in principle that could change.
This would provide support for "muted" threads, as well as allowing for negative
filtering based on messages not matched by the original search, (but present in
threads that do have at least one matched message).
The function _notmuch_message_add_thread_id has been removed
from the private interface of notmuch. There's no reason for
one to keep a declaration of its prototype in the code base.
Also, lets update a commentary that referenced that function
and escaped from previous scrutiny.
Signed-off-by: Fernando Carrijo <fcarrijo@yahoo.com.br>
This reverts commit ed16edc94d.
The performance hit is just far too severe, (threads with many HTML
messages make emacs stop and pause for seconds before displaying the
thread even if most of the HTML messages are entirely hidden).
The Debian build process (and presumably others) passes many options
to the configure script. Most of them are not needed for notmuch.
The configure script needs to just silently ignore the extra options
it's not using, so that the configure stage won't fail and the build
process can continue.
We have a bootstrapping issue with our dependency generation. When the
Makefile.config doesn't exist yet, the complete compilation flags are
not yet available for passing to the compiler to generate the
dependencies.
But we don't have explicit rules to create these dependency files,
(just the implicit rule that is created by the -include), so we can't
control when make will attempt to create them.
We do have a dependency of the dependency files on Makefile.config, so
make should eventually call the compiler with the correct flags and
everything should be good. So in the meantime, silence any complaints.
If the Makefile does this for the user, then no arguments are passed. So
it's only polite to let the user know that it's possible to get pass those
arguments.
These variables can now be set via configure time via environment
variables like so:
CFLAGS=-g ./configure
and subsequent builds will remember these values. The values can
still be overridden at compile time by passing make variables:
make CFLAGS=-O2
The CXXFLAGS variable is optional. If unset at either configure
time or at compile time, it will inherit its value from the
CFLAGS variable. (Though if explicitly set at configure time
it must be explicitly overriden at compile time---just overriding
CFLAGS will not override CXXFLAGS as well.)
The only reason I ever call "make V=1" myself, (other than when
debugging the compiler command-line for some reason), is to ensure
whether my CFLAGS, (like "-g -O0" or "-O2"), are actually making it to
the command-line.
But these are hard to find in the V=1 output, and really, we should
just print these even in the quiet case. So do that.
