[notmuch] Backport of Xapian term update optimisation

[Olly Betts]

On Thu, Feb 04, 2010 at 11:55:44AM -0500, micah anderson wrote:
> Once this is available in unstable, the notmuch package should be
> re-uploaded with a build-dependency on this version so that the package
> users see the speed improvement. As it is now, the debian package is
> pretty slow.

There's no need to rebuild notmuch to benefit from this improvement.  Just
install the updated libxapian15 package.

> What is the expected time-frame for moving this out of an experimental
> stage into unstable?

Probably a week or two.  It would be good to get this into Ubuntu Lucid (though 
oddly notmuch doesn't seem to be there yet) which means pretty soon.

If I get a lot of positive feedback on the snapshot version, that'll encourage
me to push ahead with it.  I've also announced it on the sup mailing list (as
they have similar issues with adding tags) and will on the Xapian list later
today.

> Presumably this is a more proper release by Xapian?

I would indeed prefer to put it in a new Xapian release and then package
that - if the code isn't "good enough" for an upstream release, then I'd
find it hard to justify it as "good enough" for Debian.

Cheers,
Olly

[notmuch] A functional (but rudimentary) test suite for notmuch

[Oliver Charles]

Carl, have you considered outputting the test suite in the same format
as the test anything protocol? [1] I only mention this because it
might be a nice way to easily do some reporting (or perhaps even
continuous integration) notmuch, with trivial effort.

-- 
Oliver Charles / aCiD2

[1]: http://en.wikipedia.org/wiki/Test_Anything_Protocol

[notmuch] [PATCHv2] notmuch.el: colorize lines in notmuch-search based on thread tags.

[Jameson Graef Rollins]

Arbitrary font faces can be specified for given thread tags.  By
default, no coloring is applied.  To specify coloring, place something
like this in your .emacs:

(setq notmuch-search-line-faces '(("delete" . (:foreground "red"))
  ("unread" . (:foreground "green"

Order matters: line faces listed first will take precedence (in the
example above, a thread tagged both "delete" and "unread" will be
colored red, since the "delete" face is listed before the "unread").
---
 notmuch.el |   34 +-
 1 files changed, 33 insertions(+), 1 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index a21c6a6..6c42b37 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -1203,6 +1203,36 @@ This function advances the next thread when finished."
(insert (format " (process returned %d)" 
exit-status)))
(insert "\n"))

+(defcustom notmuch-search-line-faces
+  '(("delete" . (:foreground "DarkGrey")))
+  "Tag/face mapping for line highlighting in notmuch-search.
+
+Here is an example of how to color search results based on tags.
+(the following text would be placed in your ~/.emacs file):
+
+(setq notmuch-search-line-faces '((\"delete\" . (:foreground \"red\"))
+ (\"unread\" . (:foreground \"green\"
+
+Order matters: for lines with multiple tags, the the first
+matching will be applied."
+  :type '(alist :value-type (string face))
+  :group 'notmuch)
+
+(defun notmuch-search-color-line (start end line-tag-list)
+  "Colorize lines in notmuch-search based on tags"
+  (if notmuch-search-line-faces
+  (let ((overlay (make-overlay start end))
+   (tags-faces (copy-alist notmuch-search-line-faces)))
+   (while tags-faces
+ (let* ((tag-face (car tags-faces))
+(tag (car tag-face))
+(face (cdr tag-face)))
+   (cond ((member tag line-tag-list)
+  (overlay-put overlay 'face face)
+  (setq tags-faces nil))
+ (t
+  (setq tags-faces (cdr tags-faces)
+
 (defun notmuch-search-process-filter (proc string)
   "Process and filter the output of \"notmuch search\""
   (let ((buffer (process-buffer proc)))
@@ -1220,12 +1250,14 @@ This function advances the next thread when finished."
   (authors (match-string 4 string))
   (authors-length (length authors))
   (subject (match-string 5 string))
-  (tags (match-string 6 string)))
+  (tags (match-string 6 string))
+  (tag-list (if tags (save-match-data (split-string 
tags)
  (if (> authors-length 40)
  (set 'authors (concat (substring authors 0 (- 40 3)) 
"...")))
  (goto-char (point-max))
  (let ((beg (point-marker)))
(insert (format "%s %-7s %-40s %s (%s)\n" date count 
authors subject tags))
+   (notmuch-search-color-line beg (point-marker) tag-list)
(put-text-property beg (point-marker) 
'notmuch-search-thread-id thread-id)
(put-text-property beg (point-marker) 
'notmuch-search-authors authors)
(put-text-property beg (point-marker) 
'notmuch-search-subject subject))
-- 
1.6.5

[notmuch] Git commit mails (was: New wiki instance on the notmuchmail.org website)

[martin f krafft]

also sprach Servilio Afre Puentes  [2010.02.04.1918 
+1300]:
> > If there is indeed an RSS/Atom feed on gitweb that includes the
> > diffs inline, please give me the URL; I can't fine ond.
> 
> Can't see that even in the code.

Carl, could you set up notmuch-commits at notmuchmail.org and enable
the commit and enable the mail hook as per

  http://notmuchmail.org/pipermail/notmuch/2010/001373.html

Sorry to burden you, but since you want to continue maintaining the
infrastructure, that's just what I have to do. ;)

Thanks,

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

beware of bugs in the above code;
i have only proved it correct, not tried it.
-- donald e. knuth

spamtraps: madduck.bogus at madduck.net
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100204/f975a767/attachment.pgp>

[notmuch] patchwork now auto-updates patches from Git (was: Git feature branch)

[martin f krafft]

also sprach martin f krafft  [2010.02.04.1650 +1300]:
> - … which brings me to my second point: there are certain things
>   that patchwork can do, at least in theory:
> 
>   * mark patches accepted when they hit your (canonical) master
> branch
>   * mark patches rfc when they hit e.g. my (canonical) next branch
>   * mark patches "under review" when they hit the all-patches (or
> pu) branch.
> 
>   I have not yet tried any of these, and I am basing this theory
>   only on the idea that git-patch-id can come to the rescue, for
>   there is no other linkage between the patch on the mailing list
>   (and thus known to patchwork), and the commit in the repo.

Patchwork now marks patches Accepted once they hit Carl's master
branch (up to 10 minutes delay due to Cron). It uses an algorithm
similar (but not equal) to git-patch-id in that it hashes the diff.
This means that the commit message can be amended when patches are
applied/cherry-picked, but the patch itself must be verbatim.

I ran it on all history thus far and it found 99 patches.

It'll be trivial to set it up to mark other states when the
corresponding commits hit another branch.

Let me know if there are any problems, and feedback welcome.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"if they can get you asking the wrong questions,
 they don't have to worry about answers."
 -- thomas pynchon
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Git commit mails (was: New wiki instance on the notmuchmail.org website)

[martin f krafft]

also sprach Servilio Afre Puentes  [2010.02.04.1714 
+1300]:
> In the second link, the links with the text "commitdiff" provide
> it, and you have the Atom and RSS feeds at the bottom.

As I see it, the feeds have links to the commitdiffs, but that's not
quite the same as having the diffs inline. You might be offline
without having pulled before, then the items from RSS/Atom are
useless.

If there is indeed an RSS/Atom feed on gitweb that includes the
diffs inline, please give me the URL; I can't fine ond.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

"es ist immer etwas wahnsinn in der liebe.
 es ist aber auch immer etwas vernunft im wahnsinn."
 - friedrich nietzsche

spamtraps: madduck.bogus at madduck.net
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100204/2f638b31/attachment-0001.pgp>

[notmuch] Git feature branch

[martin f krafft]

#x27;s Roundup instance? Set up
> > a patch queue manager on notmuchmail.org? Use patchwork [1]?
>
> I'm personally not interested in any system that requires me to
> push any additional buttons outside of notmuch and git itself.
> I am interested in tools that can generate reports and help
> provide visibility into things. So patchwork fixed to
> automatically notice when patches are merged would be interesting.

Absolutely. There are two comments I have:

- this gets easier the closer we get to a centralised model, simply
  because patchwork is centralised.

  We *may* be able to use Git's new "notes" feature to attach
  workflow information to patches, but for that, patches have to
  become commits in the ancestry, so we need some way of pulling
  them off the list and into the ancestry.

  Simply slurping all patches into an 'all-patches' branch won't
  work due to merge conflicts, so it has to be a manual operation
  anyway. This then either happens centrally, or we have some sort
  of communication protocol to tell others which patches have been
  integrated into the ancestry.

  This is where patchwork could come in (again).

- ? which brings me to my second point: there are certain things
  that patchwork can do, at least in theory:

  * mark patches accepted when they hit your (canonical) master
branch
  * mark patches rfc when they hit e.g. my (canonical) next branch
  * mark patches "under review" when they hit the all-patches (or
pu) branch.

  I have not yet tried any of these, and I am basing this theory
  only on the idea that git-patch-id can come to the rescue, for
  there is no other linkage between the patch on the mailing list
  (and thus known to patchwork), and the commit in the repo.

  Given that

  * git-patch-id will fail if the patch is modified before it's
applied to the ancestry,
  * git-patch-id might not work at all,
  and
  * there are status changes that cannot be deduced from Git
(rejected, superseded, not applicable, changes requested,
deferred),

  we might need some sort of protocol anyway. This could be either

  * a mail processor, in the style of the Debian bug control system,
to which you send commands like 'status 1234 superseded',
  or
  * a policy specification using e.g. Git notes on commits, such
that workflow changes could be attached to commits in a way that
would let patchwork and humans follow what's going on.

> Also interesting would be support for publishing my notmuch-based
> queue of patches to a web page.

Absolutely. As I said before, notmuch and tagging could pretty much
render patchwork obsolete, but to do that, I /think/ we need to grow
two features:

- the ability to share tags, so that I don't have to manually track
  my own patch list,
- a web archive with notmuch search/tag support.

Simply publishing your workflow statuses would be an improvement,
but I am unsure I can fully quantify the gain.

In closing, I would like draw a parallel between commits, patches
and mails:

1. notmuch deals with mails, and Git deals with commits
2. a commit can be turned into a patch and sent as a mail
3. notmuch can tag mails, Git can attach notes to commits
4. notes can be used to store tag-like information

If we continue the road of sending patches to the mailing list
(which I think is a good one, due to discussions and comments), then
we inevitably need to link commits to mails, along with the
associated metadata (tags, workflow status), in two ways.

Fun times,

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

"of course the music is a great difficulty.
 you see, if one plays good music, people don't listen,
 and if one plays bad music people don't talk."
-- oscar wilde

spamtraps: madduck.bogus at madduck.net
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100204/b21418c2/attachment.pgp>

[notmuch] [PATCHv2] notmuch.el: colorize lines in notmuch-search based on thread tags.

[Jameson Graef Rollins]

Arbitrary font faces can be specified for given thread tags.  By
default, no coloring is applied.  To specify coloring, place something
like this in your .emacs:

(setq notmuch-search-line-faces '(("delete" . (:foreground "red"))
  ("unread" . (:foreground "green"

Order matters: line faces listed first will take precedence (in the
example above, a thread tagged both "delete" and "unread" will be
colored red, since the "delete" face is listed before the "unread").
---
 notmuch.el |   34 +-
 1 files changed, 33 insertions(+), 1 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index a21c6a6..6c42b37 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -1203,6 +1203,36 @@ This function advances the next thread when finished."
(insert (format " (process returned %d)" 
exit-status)))
(insert "\n"))
 
+(defcustom notmuch-search-line-faces
+  '(("delete" . (:foreground "DarkGrey")))
+  "Tag/face mapping for line highlighting in notmuch-search.
+
+Here is an example of how to color search results based on tags.
+(the following text would be placed in your ~/.emacs file):
+
+(setq notmuch-search-line-faces '((\"delete\" . (:foreground \"red\"))
+ (\"unread\" . (:foreground \"green\"
+
+Order matters: for lines with multiple tags, the the first
+matching will be applied."
+  :type '(alist :value-type (string face))
+  :group 'notmuch)
+
+(defun notmuch-search-color-line (start end line-tag-list)
+  "Colorize lines in notmuch-search based on tags"
+  (if notmuch-search-line-faces
+  (let ((overlay (make-overlay start end))
+   (tags-faces (copy-alist notmuch-search-line-faces)))
+   (while tags-faces
+ (let* ((tag-face (car tags-faces))
+(tag (car tag-face))
+(face (cdr tag-face)))
+   (cond ((member tag line-tag-list)
+  (overlay-put overlay 'face face)
+  (setq tags-faces nil))
+ (t
+  (setq tags-faces (cdr tags-faces)
+
 (defun notmuch-search-process-filter (proc string)
   "Process and filter the output of \"notmuch search\""
   (let ((buffer (process-buffer proc)))
@@ -1220,12 +1250,14 @@ This function advances the next thread when finished."
   (authors (match-string 4 string))
   (authors-length (length authors))
   (subject (match-string 5 string))
-  (tags (match-string 6 string)))
+  (tags (match-string 6 string))
+  (tag-list (if tags (save-match-data (split-string 
tags)
  (if (> authors-length 40)
  (set 'authors (concat (substring authors 0 (- 40 3)) 
"...")))
  (goto-char (point-max))
  (let ((beg (point-marker)))
(insert (format "%s %-7s %-40s %s (%s)\n" date count 
authors subject tags))
+   (notmuch-search-color-line beg (point-marker) tag-list)
(put-text-property beg (point-marker) 
'notmuch-search-thread-id thread-id)
(put-text-property beg (point-marker) 
'notmuch-search-authors authors)
(put-text-property beg (point-marker) 
'notmuch-search-subject subject))
-- 
1.6.5
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] A functional (but rudimentary) test suite for notmuch

[Carl Worth]

On Thu, 4 Feb 2010 21:27:52 +, Oliver Charles 
 wrote:
> Carl, have you considered outputting the test suite in the same format
> as the test anything protocol? [1] I only mention this because it
> might be a nice way to easily do some reporting (or perhaps even
> continuous integration) notmuch, with trivial effort.
...
> [1]: http://en.wikipedia.org/wiki/Test_Anything_Protocol

No, I hadn't considered that. But perhaps because I wasn't at all aware
of TAP.

It looks like it would be quite trivial to switch to an output format
like that if somebody had something they'd like to hook the notmuch test
suite up to, (but I wouldn't likely switch before).

Looking at TAP, one thing I don't like is that it prints the
success/failure of the test first, before the description of the
test. That's not so nice in the case of a long-running (perhaps
infinitely running) test where you might need to interrupt it, but you'd
still want to know *what* was running for so long.

-Carl


pgpLs7PxJoY49.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] A functional (but rudimentary) test suite for notmuch

[Carl Worth]

On Thu, 4 Feb 2010 21:27:52 +, Oliver Charles  wrote:
> Carl, have you considered outputting the test suite in the same format
> as the test anything protocol? [1] I only mention this because it
> might be a nice way to easily do some reporting (or perhaps even
> continuous integration) notmuch, with trivial effort.
...
> [1]: http://en.wikipedia.org/wiki/Test_Anything_Protocol

No, I hadn't considered that. But perhaps because I wasn't at all aware
of TAP.

It looks like it would be quite trivial to switch to an output format
like that if somebody had something they'd like to hook the notmuch test
suite up to, (but I wouldn't likely switch before).

Looking at TAP, one thing I don't like is that it prints the
success/failure of the test first, before the description of the
test. That's not so nice in the case of a long-running (perhaps
infinitely running) test where you might need to interrupt it, but you'd
still want to know *what* was running for so long.

-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/20100204/a6b92ae6/attachment.pgp>

Re: [notmuch] Backport of Xapian term update optimisation

[Olly Betts]

On Thu, Feb 04, 2010 at 11:55:44AM -0500, micah anderson wrote:
> Once this is available in unstable, the notmuch package should be
> re-uploaded with a build-dependency on this version so that the package
> users see the speed improvement. As it is now, the debian package is
> pretty slow.

There's no need to rebuild notmuch to benefit from this improvement.  Just
install the updated libxapian15 package.

> What is the expected time-frame for moving this out of an experimental
> stage into unstable?

Probably a week or two.  It would be good to get this into Ubuntu Lucid (though 
oddly notmuch doesn't seem to be there yet) which means pretty soon.

If I get a lot of positive feedback on the snapshot version, that'll encourage
me to push ahead with it.  I've also announced it on the sup mailing list (as
they have similar issues with adding tags) and will on the Xapian list later
today.

> Presumably this is a more proper release by Xapian?

I would indeed prefer to put it in a new Xapian release and then package
that - if the code isn't "good enough" for an upstream release, then I'd
find it hard to justify it as "good enough" for Debian.

Cheers,
Olly
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] A functional (but rudimentary) test suite for notmuch

[Oliver Charles]

Carl, have you considered outputting the test suite in the same format
as the test anything protocol? [1] I only mention this because it
might be a nice way to easily do some reporting (or perhaps even
continuous integration) notmuch, with trivial effort.

-- 
Oliver Charles / aCiD2

[1]: http://en.wikipedia.org/wiki/Test_Anything_Protocol
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH 2/2] notmuch-reply.c: Handle munged `Reply-To' headers.

[Carl Worth]

On Sun, 29 Nov 2009 00:19:36 +0100, Jed Brown  wrote:
> Some mailing lists engage in the evil practice of changing the Reply-To
> header so that replies from all mailers go to the list by default, at
> the expense of not responding to the person who actually sent the
> message.  When this is detected, we reply to `From' and remove the
> duplicate response to the mailing list.  Consider a reply to the
> following message.

Thanks for the patch, Jed!

I've gone ahead and pushed this out, (along with some cleanups/fixes).

I augmented the notmuch test suite to actually test this case, (and the
related case of honoring Reply-To for a non-munged message). And I'm
glad I did because that turned up a bug in the patch, (using == instead
of != for the return value of strcasestr resulted in *all* messages with
a Reply-To header being considered as munged).

Here's one cleanup I made which you might find interesting as a style
issue (where I prefer naming a function based on what it *does* rather
than on what it's being *used* for):

commit d111c720bad53f98edba958aa605e857036a2bc8
Author: Carl Worth 
Date:   Thu Feb 4 12:39:11 2010 -0800

notmuch reply: Rename the mailing_list_munged_reply_to function

This function detects whether the address in the Reply-To header
already appears in either To or Cc. So give it a name that reflects
what it does (reply_to_header_is_redundant) rather than the old name
which described one possible use of the function, (as a simple
heuristic for detecting whether a mailing list had applied reply-to
munging).

-Carl


pgpSmxWhG3jxC.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH 2/2] notmuch-reply.c: Handle munged `Reply-To' headers.

[Carl Worth]

On Sun, 29 Nov 2009 00:19:36 +0100, Jed Brown  wrote:
> Some mailing lists engage in the evil practice of changing the Reply-To
> header so that replies from all mailers go to the list by default, at
> the expense of not responding to the person who actually sent the
> message.  When this is detected, we reply to `From' and remove the
> duplicate response to the mailing list.  Consider a reply to the
> following message.

Thanks for the patch, Jed!

I've gone ahead and pushed this out, (along with some cleanups/fixes).

I augmented the notmuch test suite to actually test this case, (and the
related case of honoring Reply-To for a non-munged message). And I'm
glad I did because that turned up a bug in the patch, (using == instead
of != for the return value of strcasestr resulted in *all* messages with
a Reply-To header being considered as munged).

Here's one cleanup I made which you might find interesting as a style
issue (where I prefer naming a function based on what it *does* rather
than on what it's being *used* for):

commit d111c720bad53f98edba958aa605e857036a2bc8
Author: Carl Worth 
Date:   Thu Feb 4 12:39:11 2010 -0800

notmuch reply: Rename the mailing_list_munged_reply_to function

This function detects whether the address in the Reply-To header
already appears in either To or Cc. So give it a name that reflects
what it does (reply_to_header_is_redundant) rather than the old name
which described one possible use of the function, (as a simple
heuristic for detecting whether a mailing list had applied reply-to
munging).

-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/20100204/bad9893c/attachment.pgp>

[notmuch] A functional (but rudimentary) test suite for notmuch

[Carl Worth]

I've just pushed out some improvements to make the little notmuch-test
script I had posted earlier into an actual test suite. I've included the
output of a run of the test suite below so that you can get an idea of
what it does so far.

What I'd like to see going forward is that new features get submitted
along with new test cases for the test suite. And it would be great if
everyone submitting patches could get into the habit of running:

./test/notmuch-test

before submitting.

The test suite is still extremely rudimentary. Here are some things I'd
like to improve about it:

  * Make the test suite more modular. Right now it's just one long shell
script---so it's not even easy to see where one test ends and the
next begins.

  * Allow for executing a subset of the test suite, (eg. notmuch-test reply)

I just wrote a bunch of "notmuch reply" tests and it was annoying to
have to wait for all of the "notmuch new" tests to run each time.

  * Actually document what it takes to write a test, (what the test can
assume about the environment in which its running, what functions
are available to call, etc.)

I hope others find this useful.

-Carl

Testing "notmuch new" in several variations:
 No new messages... PASS
 Single new message...  PASS
 Multiple new messages...   PASS
 No new messages (non-empty DB)...  PASS
 New directories... PASS
 Alternate inode order...   PASS
 Message moved in...PASS
 Renamed message... PASS
 Deleted message... PASS
 Renamed directory...   PASS
 Deleted directory...   PASS
 New directory (at end of list)...  PASS
 Deleted directory (end of list)... PASS
 New symlink to directory...PASS
 New symlink to a file...   PASS
 New two-level directory... PASS
 Deleted two-level directory... PASS

Testing "notmuch reply" in several variations:
 Basic reply... PASS
 Multiple recipients... PASS
 Reply with CC...   PASS
 Reply from alternate address...PASS
 Support for Reply-To...PASS
 Un-munging Reply-To... PASS
Notmuch test suite complete.


pgp4iHevPPDPK.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] A functional (but rudimentary) test suite for notmuch

[Carl Worth]

I've just pushed out some improvements to make the little notmuch-test
script I had posted earlier into an actual test suite. I've included the
output of a run of the test suite below so that you can get an idea of
what it does so far.

What I'd like to see going forward is that new features get submitted
along with new test cases for the test suite. And it would be great if
everyone submitting patches could get into the habit of running:

./test/notmuch-test

before submitting.

The test suite is still extremely rudimentary. Here are some things I'd
like to improve about it:

  * Make the test suite more modular. Right now it's just one long shell
script---so it's not even easy to see where one test ends and the
next begins.

  * Allow for executing a subset of the test suite, (eg. notmuch-test reply)

I just wrote a bunch of "notmuch reply" tests and it was annoying to
have to wait for all of the "notmuch new" tests to run each time.

  * Actually document what it takes to write a test, (what the test can
assume about the environment in which its running, what functions
are available to call, etc.)

I hope others find this useful.

-Carl

Testing "notmuch new" in several variations:
 No new messages... PASS
 Single new message...  PASS
 Multiple new messages...   PASS
 No new messages (non-empty DB)...  PASS
 New directories... PASS
 Alternate inode order...   PASS
 Message moved in...PASS
 Renamed message... PASS
 Deleted message... PASS
 Renamed directory...   PASS
 Deleted directory...   PASS
 New directory (at end of list)...  PASS
 Deleted directory (end of list)... PASS
 New symlink to directory...PASS
 New symlink to a file...   PASS
 New two-level directory... PASS
 Deleted two-level directory... PASS

Testing "notmuch reply" in several variations:
 Basic reply... PASS
 Multiple recipients... PASS
 Reply with CC...   PASS
 Reply from alternate address...PASS
 Support for Reply-To...PASS
 Un-munging Reply-To... PASS
Notmuch test suite complete.
-- 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/20100204/441f8662/attachment.pgp>

[notmuch] Backport of Xapian term update optimisation

[micah anderson]

On Thu, 4 Feb 2010 02:45:24 +, Olly Betts  wrote:
> On Wed, Feb 03, 2010 at 02:35:14PM -0500, Jameson Rollins wrote:
> > On Thu, 28 Jan 2010 00:06:59 + (UTC), Olly Betts  
> > wrote:
> >
> > I just installed this new version from a Debian experimental repo,
> > rebuilt notmuch against the new installation, and everything seems to be
> > working great.  I'll report back any issues to the BTS.  Thanks again.
> 
> Thanks.  Are you seeing the expected speed improvement?

Once this is available in unstable, the notmuch package should be
re-uploaded with a build-dependency on this version so that the package
users see the speed improvement. As it is now, the debian package is
pretty slow.

What is the expected time-frame for moving this out of an experimental
stage into unstable? Presumably this is a more proper release by Xapian?

micah
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100204/ad448ea1/attachment.pgp>

[notmuch] Git commit mails (was: New wiki instance on the notmuchmail.org website)

[martin f krafft]

also sprach David Bremner  [2010.02.04.0924 +1300]:
> > PS: speaking of prefixes, how about remving the subject prefix of
> > this list in general? ;)
> 
> I used to agree, but in notmuch, I actually find it convenient to have
> threads marked by mailing list. Perhaps this will change if/when my
> email setup or the notmuch emacs ui get better...

sed -e 's,^Subject:,& [notmuch],'

;)

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

apt-get source --compile gentoo

spamtraps: madduck.bogus at madduck.net
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100204/c76639a5/attachment.pgp>

[notmuch] Git commit mails (was: New wiki instance on the notmuchmail.org website)

[martin f krafft]

also sprach Marten Veldthuis  [2010.02.04.0353 +1300]:
> > Like this? http://notmuchmail.org/recentchanges/
> 
> No, more like this: http://git.notmuchmail.org/git/notmuch-wiki

To my knowledge, neither of these two give you diffs. This is what
a post-receive hook offers.

It's trivial to do with Git. Assuming a recent Git-on-Debian, it's
just (assuming you are in the bare repository)

  test -d refs || echo not in repo
  sed -e 's,^#\.,,' hooks/post-receive.sample > hooks/post-receive
  chmod 755 !$
  git config hooks.mailinglist notmuch at notmuchmail.org

One might also have to send hooks.envelopesender and
hooks.emailprefix (without trailing space) could be nice.

PS: speaking of prefixes, how about remving the subject prefix of
this list in general? ;)

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

"arguments are extremely vulgar,
 for everyone in good society
 holds exactly the same opinion."
-- oscar wilde

spamtraps: madduck.bogus at madduck.net
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100204/510a1eee/attachment.pgp>

Re: [notmuch] Backport of Xapian term update optimisation

[micah anderson]

On Thu, 4 Feb 2010 02:45:24 +, Olly Betts  wrote:
> On Wed, Feb 03, 2010 at 02:35:14PM -0500, Jameson Rollins wrote:
> > On Thu, 28 Jan 2010 00:06:59 + (UTC), Olly Betts  
> > wrote:
> >
> > I just installed this new version from a Debian experimental repo,
> > rebuilt notmuch against the new installation, and everything seems to be
> > working great.  I'll report back any issues to the BTS.  Thanks again.
> 
> Thanks.  Are you seeing the expected speed improvement?

Once this is available in unstable, the notmuch package should be
re-uploaded with a build-dependency on this version so that the package
users see the speed improvement. As it is now, the debian package is
pretty slow.

What is the expected time-frame for moving this out of an experimental
stage into unstable? Presumably this is a more proper release by Xapian?

micah


pgp5MkjbGfU3a.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH] notmuch.el: colorize lines in notmuch-search based on thread tags.

[Jameson Rollins]

Arbitrary font faces can be specified for given thread tags.  By
default, no coloring is applied.  To specify coloring, place something
like this in your .emacs:

(setq notmuch-search-line-faces '(("delete" . '(:foreground "red"))
  ("unread" . '(:foreground "green"

Order matters: line faces listed first will take precedence (in the
example above, a thread tagged both "delete" and "unread" will be
colored red, since the "delete" face is listed before the "unread").
---
 notmuch.el |   33 -
 1 files changed, 32 insertions(+), 1 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index a21c6a6..4f8840a 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -1203,6 +1203,35 @@ This function advances the next thread when finished."
(insert (format " (process returned %d)" 
exit-status)))
(insert "\n"))

+(defcustom notmuch-search-line-faces nil
+  "Tag/face mapping for line highlighting in notmuch-search.
+
+Here is an example of how to color search results based on tags.
+(the following text would be placed in your ~/.emacs file):
+
+(setq notmuch-search-line-faces '((\"delete\" . '(:foreground \"red\"))
+ (\"unread\" . '(:foreground \"green\"
+
+Order matters: for lines with multiple tags, the the first
+matching will be applied."
+  :type '(alist :key-type (string) :value-type (list))
+  :group 'notmuch)
+
+(defun notmuch-search-color-line (start end line-tag-list)
+  "Colorize lines in notmuch-show based on tags"
+  (if notmuch-search-line-faces
+  (let ((overlay (make-overlay start end))
+   (tags-faces (copy-alist notmuch-search-line-faces)))
+   (while tags-faces
+ (let* ((tag-face (car tags-faces))
+(tag (car tag-face))
+(face (cdr tag-face)))
+   (cond ((member tag line-tag-list)
+  (overlay-put overlay 'face face)
+  (setq tags-faces nil))
+ (t
+  (setq tags-faces (cdr tags-faces)
+
 (defun notmuch-search-process-filter (proc string)
   "Process and filter the output of \"notmuch search\""
   (let ((buffer (process-buffer proc)))
@@ -1220,12 +1249,14 @@ This function advances the next thread when finished."
   (authors (match-string 4 string))
   (authors-length (length authors))
   (subject (match-string 5 string))
-  (tags (match-string 6 string)))
+  (tags (match-string 6 string))
+  (tag-list (if tags (save-match-data (split-string 
tags)
  (if (> authors-length 40)
  (set 'authors (concat (substring authors 0 (- 40 3)) 
"...")))
  (goto-char (point-max))
  (let ((beg (point-marker)))
(insert (format "%s %-7s %-40s %s (%s)\n" date count 
authors subject tags))
+   (notmuch-search-color-line beg (point-marker) tag-list)
(put-text-property beg (point-marker) 
'notmuch-search-thread-id thread-id)
(put-text-property beg (point-marker) 
'notmuch-search-authors authors)
(put-text-property beg (point-marker) 
'notmuch-search-subject subject))
-- 
1.6.5

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100204/1be99af6/attachment.pgp>

[notmuch] [PATCH] notmuch.el: colorize lines in notmuch-search based on thread tags.

[Jameson Rollins]

Arbitrary font faces can be specified for given thread tags.  By
default, no coloring is applied.  To specify coloring, place something
like this in your .emacs:

(setq notmuch-search-line-faces '(("delete" . '(:foreground "red"))
  ("unread" . '(:foreground "green"

Order matters: line faces listed first will take precedence (in the
example above, a thread tagged both "delete" and "unread" will be
colored red, since the "delete" face is listed before the "unread").
---
 notmuch.el |   33 -
 1 files changed, 32 insertions(+), 1 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index a21c6a6..4f8840a 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -1203,6 +1203,35 @@ This function advances the next thread when finished."
(insert (format " (process returned %d)" 
exit-status)))
(insert "\n"))
 
+(defcustom notmuch-search-line-faces nil
+  "Tag/face mapping for line highlighting in notmuch-search.
+
+Here is an example of how to color search results based on tags.
+(the following text would be placed in your ~/.emacs file):
+
+(setq notmuch-search-line-faces '((\"delete\" . '(:foreground \"red\"))
+ (\"unread\" . '(:foreground \"green\"
+
+Order matters: for lines with multiple tags, the the first
+matching will be applied."
+  :type '(alist :key-type (string) :value-type (list))
+  :group 'notmuch)
+
+(defun notmuch-search-color-line (start end line-tag-list)
+  "Colorize lines in notmuch-show based on tags"
+  (if notmuch-search-line-faces
+  (let ((overlay (make-overlay start end))
+   (tags-faces (copy-alist notmuch-search-line-faces)))
+   (while tags-faces
+ (let* ((tag-face (car tags-faces))
+(tag (car tag-face))
+(face (cdr tag-face)))
+   (cond ((member tag line-tag-list)
+  (overlay-put overlay 'face face)
+  (setq tags-faces nil))
+ (t
+  (setq tags-faces (cdr tags-faces)
+
 (defun notmuch-search-process-filter (proc string)
   "Process and filter the output of \"notmuch search\""
   (let ((buffer (process-buffer proc)))
@@ -1220,12 +1249,14 @@ This function advances the next thread when finished."
   (authors (match-string 4 string))
   (authors-length (length authors))
   (subject (match-string 5 string))
-  (tags (match-string 6 string)))
+  (tags (match-string 6 string))
+  (tag-list (if tags (save-match-data (split-string 
tags)
  (if (> authors-length 40)
  (set 'authors (concat (substring authors 0 (- 40 3)) 
"...")))
  (goto-char (point-max))
  (let ((beg (point-marker)))
(insert (format "%s %-7s %-40s %s (%s)\n" date count 
authors subject tags))
+   (notmuch-search-color-line beg (point-marker) tag-list)
(put-text-property beg (point-marker) 
'notmuch-search-thread-id thread-id)
(put-text-property beg (point-marker) 
'notmuch-search-authors authors)
(put-text-property beg (point-marker) 
'notmuch-search-subject subject))
-- 
1.6.5



pgpUXAV2Sgirp.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Backport of Xapian term update optimisation

[Olly Betts]

On Wed, Feb 03, 2010 at 02:35:14PM -0500, Jameson Rollins wrote:
> On Thu, 28 Jan 2010 00:06:59 + (UTC), Olly Betts  
> wrote:
> > I've backported the term update optimisation patches
> >  to Xapian's 1.0 branch, and you can
> > find snapshot tarballs including these changes here:
> > 
> > http://oligarchy.co.uk/xapian/branches/1.0/
> > 
> > Xapian's testsuite passes (including the additional test coverage which I
> > also backported), and I looked over each change carefully, but I would be
> > interested to see some real world testing, particularly in the situation
> > which these changes are intended to improve (i.e. speed of tagging in
> > notmuch).
> 
> Hey, Olly.  Thanks so much for backporting this patch and uploading a
> patched package to Debian experimental (which is now available):

It hasn't built for all Debian architectures yet, but is available for at
least amd64 and x86, which are probably the most popular two.

If you aren't sure how to pull in packages from experimental, see:

http://wiki.debian.org/DebianExperimental

I've also put it in a Launchpad PPA for all currently supported Ubuntu
releases, which has built for all of them already:

https://launchpad.net/~ojwb/+archive/experimental/

> I just installed this new version from a Debian experimental repo,
> rebuilt notmuch against the new installation, and everything seems to be
> working great.  I'll report back any issues to the BTS.  Thanks again.

Thanks.  Are you seeing the expected speed improvement?

Cheers,
Olly

[notmuch] Git commit mails (was: New wiki instance on the notmuchmail.org website)

[Servilio Afre Puentes]

On 4 February 2010 00:05, martin f krafft  wrote:
> also sprach Servilio Afre Puentes  [2010.02.04.1714 
> +1300]:
>> In the second link, the links with the text "commitdiff" provide
>> it, and you have the Atom and RSS feeds at the bottom.
>
> As I see it, the feeds have links to the commitdiffs, but that's not
> quite the same as having the diffs inline.

Oh, diffs inline.

[...]
> If there is indeed an RSS/Atom feed on gitweb that includes the
> diffs inline, please give me the URL; I can't fine ond.

Can't see that even in the code.

Servilio