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
---
notmuch.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
d
> But you might actually like that change since it's one you requested in
> your first version of the modular test suite. I'm dropping the annoying
> execute_expecting macro that both runs notmuch and tests the
> output. There's now a much cleaner separation such as:
>
> output=$($NOTMUCH se
On 2010-04-16, Dirk Hohndel wrote:
> +Thirdparty apps
> +---
> +(not sure this is the best spot to collect requests like this)
> +
> +notmuchsync
> +
> +Add feature to move files in the maildir hierarchy
> +
> + notmuchsync --move "searchstring" "targetfolder"
> + Where searchst
On Thu, 15 Apr 2010 18:46:56 -0700, Carl Worth wrote:
> On Thu, 15 Apr 2010 16:04:38 -0400, Jesse Rosenthal
> wrote:
> > the region command only executes one "notmuch tag" command over
> > "id:X or id:Y or id:Z or ...".
>
> ...this operation is all set up to run into "argument list too long"
>
Search output was already using `timestamp' for a very similar field,
so follow that.
---
notmuch-show.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/notmuch-show.c b/notmuch-show.c
index 76873a1..26449fa 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -145,7 +145,
On Wed, 14 Apr 2010 17:35:44 -0700, Carl Worth wrote:
> [*] I say "should" because I don't believe we have any actual
> specification of the data coming out of the JSON output yet. One other
> thing that seems odd is the name of "date_unix" in the show output and
> "timestamp" in the search output
On 15 April 2010 21:46, Carl Worth wrote:
[...]
> We'll probably need to arrange for notmuch to accept search
> specifications on stdin or so.
Or a daemon mode with a pipe or DBus interface.
Servilio
___
notmuch mailing list
notmuch@notmuchmail.org
htt
On Thu, 15 Apr 2010 17:27:17 -0400, Jameson Rollins
wrote:
> Does anyone know how to "bounce" a message,
pipe the message to "sendmail u...@axample.com"
Well, ok, mutt adds "Resent-*" headers to the bounced message, so there
it's not unaltered.
Peter
___
On Fri, 16 Apr 2010 09:06:02 +0200, Sebastian Spaeth
wrote:
> 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.
Thanks for the reminder. Pushed.
-Carl
On Fri, 16 Apr 2010 10:34:53 +0200, Peter Wiersig
wrote:
> On Thu, 15 Apr 2010 17:27:17 -0400, Jameson Rollins
> wrote:
> > Does anyone know how to "bounce" a message,
>
> pipe the message to "sendmail u...@axample.com"
>
> Well, ok, mutt adds "Resent-*" headers to the bounced message, so the
This is the second release of the notmuch mail system, with actual
detailed release notes this time!
This release consists of a number of minor new features that make
notmuch more pleasant to use, and a few fairly major bug fixes.
We didn't quite hit our release target of "about a week" from the
I'm officially opening the merge window for the upcoming 0.3 release
(about a week from now).
I know that I want to merge David Edmunson's rewrite of the emacs
interface to be built on top of --format=json and add a ton of features,
(better attachment handling, notmuch-hello, etc.). I think that's
The following two patches should address most of the concerns raised
to my previous series.
The first patch simply adds an interface to obtain a concatenation of
all instances of a specific header from an email.
The second patch uses that in order to get the full Received: headers.
It now looks
We now look at Envelope-To: and Original-To: headers
Then concat all of the Received headers and walk through them to find
either a "for em...@add.res" clause or a host in a known domain.
This should deal with most of the fetchmail and mail hoster induced
pain (and failure) of the old heuristic.
notmuch_message_get_header only returns the first instance of the specified
header in a message.
notmuch_message_get_concat_header concatenates the values from ALL instances
of that header in a message. This is useful for example to get the full
delivery path as captured in all of the Received: hea
Hi,
I'm not sure whether replying to the announcement email is the
appropriate way to report building and testing results, but here goes.
notmuch-0.2 built fine, but one test failed during 'make test'. I have
put the indicated directory up at
http://aghitza.org/files/test.16707
with a tarred
On 2010-04-15, Olly Betts wrote:
> > I would be happy to have it called --sort=relevance too, the unsorted
> > points out potential performance improvements a bit better, IMHO
> > (although they seem to be really small with a warm cache).
>
> When using the results of a search to add/remove tags,
Previously, we always sorted the returned results by some string value,
(newest-to-oldest by default), however in some cases (as when applying
tags to a search result) we are not interested in any special order.
This introduces a NOTMUCH_SORT_UNSORTED value that does just that. It is
not used at t
In some cases, we might not be interested in any special sort order, so
this introduces a --sort=unsorted command line option together with its
documentation.
Signed-off-by: Sebastian Spaeth
---
notmuch-search.c |2 ++
notmuch.1| 10 ++
notmuch.c|7 ---
3 fi
It's not neccessary to sort the results before we apply tags. Xapian
contributor Olly Betts says that savings might be bigger with a cold
file cache and (as unsorted implies really sorted by document id) a better
cache locality when applying tags to messages.
Signed-off-by: Sebastian Spaeth
---
On Fri, Apr 16, 2010 at 08:37:04AM +0200, Sebastian Spaeth wrote:
> On 2010-04-15, Olly Betts wrote:
> > Also, sorting by relevance requires more calculations and may require
> > fetching additional data (document length for example).
> >
> > So I think it would make sense for --sort=relevance and
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
---
notmuch.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
d
> But you might actually like that change since it's one you requested in
> your first version of the modular test suite. I'm dropping the annoying
> execute_expecting macro that both runs notmuch and tests the
> output. There's now a much cleaner separation such as:
>
> output=$($NOTMUCH se
On 2010-04-16, Dirk Hohndel wrote:
> +Thirdparty apps
> +---
> +(not sure this is the best spot to collect requests like this)
> +
> +notmuchsync
> +
> +Add feature to move files in the maildir hierarchy
> +
> + notmuchsync --move "searchstring" "targetfolder"
> + Where searchst
On Thu, 15 Apr 2010 18:46:56 -0700, Carl Worth wrote:
> On Thu, 15 Apr 2010 16:04:38 -0400, Jesse Rosenthal
> wrote:
> > the region command only executes one "notmuch tag" command over
> > "id:X or id:Y or id:Z or ...".
>
> ...this operation is all set up to run into "argument list too long"
>
Search output was already using `timestamp' for a very similar field,
so follow that.
---
notmuch-show.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/notmuch-show.c b/notmuch-show.c
index 76873a1..26449fa 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -145,7 +145,
On Wed, 14 Apr 2010 17:35:44 -0700, Carl Worth wrote:
> [*] I say "should" because I don't believe we have any actual
> specification of the data coming out of the JSON output yet. One other
> thing that seems odd is the name of "date_unix" in the show output and
> "timestamp" in the search output
On 15 April 2010 21:46, Carl Worth wrote:
[...]
> We'll probably need to arrange for notmuch to accept search
> specifications on stdin or so.
Or a daemon mode with a pipe or DBus interface.
Servilio
On Thu, 15 Apr 2010 17:27:17 -0400, Jameson Rollins wrote:
> Does anyone know how to "bounce" a message,
pipe the message to "sendmail user at axample.com"
Well, ok, mutt adds "Resent-*" headers to the bounced message, so there
it's not unaltered.
Peter
the reminder. Pushed.
-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100416/16b4ac6a/attachment.pgp>
ation/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100416/fa824523/attachment.pgp>
much
===
Notmuch is a system for indexing, searching, reading, and tagging
large collections of email messages in maildir or mh format. It uses
the Xapian library to provide fast, full-text search with a convenient
search syntax.
For more about notmuch, see http://notmuchmail.org
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100416/5bbdfba8/attachment.pgp>
ttachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100416/86b2c7b6/attachment.pgp>
The following two patches should address most of the concerns raised
to my previous series.
The first patch simply adds an interface to obtain a concatenation of
all instances of a specific header from an email.
The second patch uses that in order to get the full Received: headers.
It now looks
We now look at Envelope-To: and Original-To: headers
Then concat all of the Received headers and walk through them to find
either a "for email at add.res" clause or a host in a known domain.
This should deal with most of the fetchmail and mail hoster induced
pain (and failure) of the old heuristic
notmuch_message_get_header only returns the first instance of the specified
header in a message.
notmuch_message_get_concat_header concatenates the values from ALL instances
of that header in a message. This is useful for example to get the full
delivery path as captured in all of the Received: hea
36 matches
Mail list logo
