When there is no configuration file at all, (and none specified),
notmuch works correctly by assuming correct default values. But when
the user specifies a configuration file (with the NOTMUCH_CONFIG
environment variable) and that file doesn't exist, then notmuch should
aboirt and let the user know about the problem.
The thread-naming feature depends on the matched messages being passed
down in a precise order, (the order of the top-level search). We fix
the feature by passing that sort order down.
We recently added a feature to name threads based on the messages that
actually matched the search, (as opposed to simply the oldest or
newest message in the thread whether it matched or not). So add tests
for that, and (surprise, surprise!) the feature does not entirely
work.
We know that matched messages are always added in order, so we can
always just grab the subject from the first message. This is the same
approach that was used previously in _thread_add_message. That is, the
recent feature of renaming a thread based on the subject of the
"first" matched message is as simple as moving the subject assignment
from _thread_add_message to _thread_add_matched_message.
At the moment all threads are named based on the name of the first message
in the thread. However, this can cause problems if people either start
new threads by replying-all (as unfortunately, many out there do) or
change the subject of their mails to reflect a shift in a thread on a
list.
This patch names threads based on (a) matches for the query, and (b) the
search order. If the search order is oldest-first (as in the default
inbox) it chooses the oldest matching message as the subject. If the
search order is newest-first it chooses the newest one.
Reply prefixes ("Re: ", "Aw: ", "Sv: ", "Vs: ") are ignored
(case-insensitively) so a Re: won't change the subject.
Note that this adds a "sort" argument to _notmuch_thread_create and
_thread_add_matched_message, so that when constructing the thread we can
be aware of the sort order.
Signed-off-by: Jesse Rosenthal <jrosenthal@jhu.edu>
This way when GMime 2.8 comes out we can simply add it to the list
rather than adding an additional block of conditional code for it.
Also GMime 2.6 is now preferred over GMime 2.4.
This patch helps in customizing search result display similar to
mutt's index_format. The customization is done by defining an alist as
below:
(setq notmuch-search-result-format '(("date" . "%s ")
("authors" . "%-40s ")
("subject" . "%s ")))
The supported keywords are date, count, authors, subject and tags.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: David Edmondson <dme@dme.org>
Use the mailcap functionality to guess a MIME type for attachments of
type application/octet-stream and, presuming successful, feed the
attachment back into the display code with the determine type.
This is mostly useless at the moment, as the JSON output from notmuch
does not include the content of application/octet-stream parts, so
they cannot be displayed even if the guess is a good one.
If a text/plain part is not the first part in a message, add a label
in order that a user can see that multiple parts are present.
If a part has a 'filename' attribute, include it in any label
describing the part.
In the recent switch to a JSON-based emacs interface, RET now toggles
message visibility anywhere in the message, (rather than only on the
summary line). So we no longer need this separate "b" binding for this.
Additionally, the body toggle was implemented independently from RET,
so after hiding a message with "b" one could not make it visible with
RET. This confusing state is now no longer possible, (since the
:body-visible property is removed entirely).
The special case for len==0 was wrong---the normal code path is to
talloc to get a newly allocated, editable string, that might be
talloc_free'd later. It makes more sense just to let the len==0
behaviour fall through into the normal case code.
Reviewed-by: Carl Worth <cworth@cworth.org>
This results in the same value being returned, but with the proper
memory handling.
Eventually I'd like to automate this so that one or the other of these
files is canonical and the other is generated from it. Until then, add
this check to the release process to avoid a skewed release being
shipped.
On Linux, a C program that depends on a C library which in turn
depends on a C++ can be linked with the C compiler, (avoiding a direct
link from the program to the C++ runtime libraries).
Other platforms with less fancy linkers need to use the C++ compiler
for this linking.
Useful for verifying that our tar-file creation works. The tar-file
name can't easily be used as a target directly since it depends on the
current git revision.
Theese were previously pointing to "make VERSION=X.Y release", but
we've recently changed to an alternate scheme involving the updated
version in a file named "version".
We do this so that "git archive" produces a usable tar file without us
having to post-modify it, (since tools like git-buildpackage might not
give us an easy way to hook into the tar-file-creation step).
To support this we also have to change our preference to prefer the
git-described-based version (if available) and only if not available
do we fallback to using what's in the "version" file. Finally, we also
ovverride this preference when releasing, (where what's in the
"version" file wins).
Note that using our Makefile's rule to create a tar file still will
insert the git-based version into the tar file. This is useful for
creating snapshots which will correctly report the git version from
which they were created.
David Bremner informs me that shoving everything from the notmuch "git
log" into the debian/changelog is a bit excessive. Instead, we'll
start manually updating this file, (which feels a bit redundant with
NEWS, but perhaps makes us a better Debian-comunity member).
On Bdale Garbee's recommendation I'm switching from gitpkg, (which
constructed a source tree but still required me to go run debuild), to
git-buildpackage. I hadn't originally used git-buildpackage because it
didn't seem to work without a configuration file, (where gitpkg was
fine).
Bdale was kind enough to point me to his fw/altos source at
git.gag.com where I found an example gpb.conf file as well as a target
in debian/rules to automatically update debian/changelog with the new
version number.
This reverts commit fbec989fe3.
I only pushed this accidentally. See message
id:871ver6u9r.fsf@yoom.home.cworth.org for the various reasons I
didn't like this patch, (mostly I think the association of 'F' is
wrong).
We previously output "notmuch version 0.1" as response to notmuch --version.
Shorten this to "notmuch 0.1" as we know that we will receive a version
number when we explicitely ask for it.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
With the recent addition of "*" being a special case for a search
matching all messages, we have to take care when doing a filter
operation. In this case it's not legal to simply append and get:
* and <some-new-search-terms>
Instead we carefully construct a new search string of only:
<some-new-search-terms>
This could all be avoided if we had a parser that could understand
"*" with the meaning we want.
It was noted today in IRC that libnotmuch is not yet careful about
wrapping all Xapian calls with try/catch blocks to print nicer error
messages. It seems it would be natural to audit that at the same time
as doing the symbol-hiding work.
We actually want this version to be incremented by the commits that
extend the interface. So the release process really is not to just
verify two things (NEWS and libnotmuch version), then run "make
VERSION=x.y release", and send the mail. Quite nice.
The entire "make sure the code you want is in place" thing is part of
a larger release process that we don't document here at all. Instead,
we just focus here on the mechanics of pushing things out once the
larger process has determined the code is ready.
And the fewer steps there are, the better, (for making the
release-process as painless as possible and for avoiding any
mistakes).
