Emacs: Crypto: How to get automatic encryption?

2012-01-12 Thread Darren McGuicken
On Thu, 12 Jan 2012 20:05:14 +0100, Gregor Zattler  wrote:
> 2) encrypt if suitable public keys for all recipients are in
>GnuPGs key ring.
[...]
> But I have no clue about how to do this with notmuch/Emacs.

Isn't that what David provides an elisp-snippet for in
id:"cunk4576ezs.fsf at hotblack-desiato.hh.sledj.net"?

I've been using it myself since it was posted and it seems to work
according to the behaviour you desire in point 2.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



Re: Emacs: Crypto: How to get automatic encryption?

2012-01-12 Thread Darren McGuicken
On Thu, 12 Jan 2012 20:05:14 +0100, Gregor Zattler telegr...@gmx.net wrote:
 2) encrypt if suitable public keys for all recipients are in
GnuPGs key ring.
[...]
 But I have no clue about how to do this with notmuch/Emacs.

Isn't that what David provides an elisp-snippet for in
id:cunk4576ezs@hotblack-desiato.hh.sledj.net?

I've been using it myself since it was posted and it seems to work
according to the behaviour you desire in point 2.


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


Regarding notmuch and Fedora 16

2012-01-03 Thread Darren McGuicken
On Tue, 03 Jan 2012 17:09:39 -0500, Peter Portante  wrote:
> I am interested in using notmuch from within emacs, but have not been 
> able to get the latest version of notmuch (0.10.2) to compile under 
> Fedora 16.

Looks like we have a growing Fedora community, yay! :-)

And it's nothing you're doing wrong, per my reply to the other thread
F16 is using the current development version of gmime which has API
differences with the stable version 2.4.  The patch that exists isn't
part of standard notmuch since it in turn breaks 2.4 compatibility.

What's the right way to handle this?  I see 2.6 tarballs on gnome... is
2.6 officially out there and stable?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



[ANNOUNCE] mutt with notmuch support

2012-01-03 Thread Darren McGuicken
On Tue, 03 Jan 2012 13:17:04 -0800, Jameson Graef Rollins  wrote:
> On Tue, 3 Jan 2012 20:59:51 +0100, Karel Zak  wrote:
> > Unfortunately, the latest package for Fedora is notmuch-0.5-4.fc15 ;-(
> 
> Yikes that's old (0.11 is being released eminently).  There have been
> quite a few important changes since then.  Is there no one actively
> maintaining the fedora package?  Obviously there's not.  Anyone willing
> to take this on?

The problem is probably the use of gmime 2.5+ in Fedora.  We don't
currently seem to have a patchset which allows compilation across both
gmime <=2.4 and >=2.5, although we can do either/or.

There's also a build of 0.9 in koji:

http://koji.fedoraproject.org/koji/packageinfo?packageID=11257
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



[ANNOUNCE] mutt with notmuch support

2012-01-03 Thread Darren McGuicken
On Tue, 3 Jan 2012 20:59:51 +0100, Karel Zak  wrote:
> Unfortunately, the latest package for Fedora is notmuch-0.5-4.fc15 ;-(

Take a look at id:"8762i8hrb9.fsf at bookbinder.fernseed.info".  There is a
gmime patch which still applies cleanly to everything up to the current
git head and which will let you build your own Fedora package.  I'm
using it myself with no issues.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



[ANNOUNCE] mutt with notmuch support

2012-01-03 Thread Darren McGuicken
On Tue, Jan 03, 2012 at 01:39:38PM +0100, Karel Zak wrote:
> This is not another curses front-end for notmuch, this is mutt :-)

Outstanding!  Assuming this mail makes it to the list, I can confirm that it 
works well for me!  Although I will have to find and dust off an old .muttrc...

I had to tweak your use of notmuch_database_find_message (I'm using 0.11_rc2) 
but otherwise it compiles fine.  Thanks so much for this.  Is the intent that 
this remains a fork, or will it find its way back into upstream?


Re: [ANNOUNCE] mutt with notmuch support

2012-01-03 Thread Darren McGuicken
On Tue, 3 Jan 2012 20:59:51 +0100, Karel Zak k...@redhat.com wrote:
 Unfortunately, the latest package for Fedora is notmuch-0.5-4.fc15 ;-(

Take a look at id:8762i8hrb9@bookbinder.fernseed.info.  There is a
gmime patch which still applies cleanly to everything up to the current
git head and which will let you build your own Fedora package.  I'm
using it myself with no issues.


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


Re: [ANNOUNCE] mutt with notmuch support

2012-01-03 Thread Darren McGuicken
On Tue, 03 Jan 2012 13:17:04 -0800, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 On Tue, 3 Jan 2012 20:59:51 +0100, Karel Zak k...@redhat.com wrote:
  Unfortunately, the latest package for Fedora is notmuch-0.5-4.fc15 ;-(
 
 Yikes that's old (0.11 is being released eminently).  There have been
 quite a few important changes since then.  Is there no one actively
 maintaining the fedora package?  Obviously there's not.  Anyone willing
 to take this on?

The problem is probably the use of gmime 2.5+ in Fedora.  We don't
currently seem to have a patchset which allows compilation across both
gmime =2.4 and =2.5, although we can do either/or.

There's also a build of 0.9 in koji:

http://koji.fedoraproject.org/koji/packageinfo?packageID=11257


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


Re: Regarding notmuch and Fedora 16

2012-01-03 Thread Darren McGuicken
On Tue, 03 Jan 2012 17:09:39 -0500, Peter Portante peter.a.porta...@gmail.com 
wrote:
 I am interested in using notmuch from within emacs, but have not been 
 able to get the latest version of notmuch (0.10.2) to compile under 
 Fedora 16.

Looks like we have a growing Fedora community, yay! :-)

And it's nothing you're doing wrong, per my reply to the other thread
F16 is using the current development version of gmime which has API
differences with the stable version 2.4.  The patch that exists isn't
part of standard notmuch since it in turn breaks 2.4 compatibility.

What's the right way to handle this?  I see 2.6 tarballs on gnome... is
2.6 officially out there and stable?


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


S/MIME support in notmuch

2011-12-21 Thread Darren McGuicken
On Wed, 07 Dec 2011 21:58:03 -0500, Dan Bryant  wrote:
> I'd like to report some success on getting S/MIME signature
> verification working using notmuch and the recently-released GMime
> 2.6. I specifically tested with notmuch-0.10.2 and gmime-2.6.1.

[...]

> I don't have submittable patches for #2/#3 yet, but I wanted to share
> what I found about the scope of what actually needs to be done, which
> is fairly small. (The biggest blocker is probably that Debian & other
> distros haven't packaged gmime-2.6.)

Hi Dan, nice find!  As another Fedora user I'd be happy to test out any
patches you come up with.

When you make those changes to the gpg_context are you breaking gpg
signature validation?  Or is the one a superset of the other?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



Re: S/MIME support in notmuch

2011-12-21 Thread Darren McGuicken
On Wed, 07 Dec 2011 21:58:03 -0500, Dan Bryant dan.bry...@jhuapl.edu wrote:
 I'd like to report some success on getting S/MIME signature
 verification working using notmuch and the recently-released GMime
 2.6. I specifically tested with notmuch-0.10.2 and gmime-2.6.1.

[...]

 I don't have submittable patches for #2/#3 yet, but I wanted to share
 what I found about the scope of what actually needs to be done, which
 is fairly small. (The biggest blocker is probably that Debian  other
 distros haven't packaged gmime-2.6.)

Hi Dan, nice find!  As another Fedora user I'd be happy to test out any
patches you come up with.

When you make those changes to the gpg_context are you breaking gpg
signature validation?  Or is the one a superset of the other?


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


compile error of current git on F15

2011-11-25 Thread Darren McGuicken
On Fri, 25 Nov 2011 13:43:35 -0500, David Bremner  wrote:
> Just confirm, all the crypto tests pass with this patch? In that case,
> can we have the patch (preferably as generated by git-send-email)? Or
> did I miss it somewhere in this thread?

I don't believe the patch ever made it to the list, I can't find it in
my own archive.  From the changelog here:

  http://koji.fedoraproject.org/koji/buildinfo?buildID=269819

  it looks like Karel Kl?? of Red Hat created it back in July, I assume
that's when Fedora moved to the later GMime version.

The patch itself looks like it's a straight re-mapping of the 2.4
GMimeSignatureValidity to the 2.5+ equivalent along with some
deprecation of GMimeSession, so just applying the patch will break
compilation for anyone < 2.5.

Also, three of the crypto tests relating to signature validation /do/
fail, although it looks like that may simply be down to changes in the
output format and so just need updated test cases.

I've attached the patch as-is to this mail for reference purposes, but
based on the above it'll need a bit of tweaking before it's useful to
the wider group.

-- next part --
A non-text attachment was scrubbed...
Name: notmuch-0.6.1-gmime.patch
Type: text/x-patch
Size: 9862 bytes
Desc: Fedora GMime Patch
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



compile error of current git on F15

2011-11-24 Thread Darren McGuicken
On Wed, 01 Jun 2011 09:55:16 -0700, Jameson Graef Rollins  wrote:
> On Wed, 01 Jun 2011 05:35:29 -0700, Dirk Hohndel  
> wrote:
> > This used to work and used to be supported and was broken in a
> > recent notmuch patch.
>
> If you don't have access to gmime 2.4, then maybe you could look into
> providing patches for gmime 2.6 support, or alternately into disabling
> the notmuch functionality that does not work with gmime 2.6 if only
> 2.6 is available.

Hi guys, I assume this is old news, although I haven't seen anything
else mentioned on list since the chain Dirk started - there's a koji
build of 0.9 for rawhide, the source rpm of which contains a gmime 2.6
patch.  I recently moved from Ubuntu to Fedora 16 on the netbook so I
grabbed the patch and spec file, updated it to point to the 0.10 tarball
and can confirm that the patch still applies cleanly and the notmuch
build appears fine (crypto et al).

Assuming this mail sends, of course :-)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



Re: compile error of current git on F15

2011-11-24 Thread Darren McGuicken
On Wed, 01 Jun 2011 09:55:16 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 On Wed, 01 Jun 2011 05:35:29 -0700, Dirk Hohndel hohn...@infradead.org 
 wrote:
  This used to work and used to be supported and was broken in a
  recent notmuch patch.

 If you don't have access to gmime 2.4, then maybe you could look into
 providing patches for gmime 2.6 support, or alternately into disabling
 the notmuch functionality that does not work with gmime 2.6 if only
 2.6 is available.

Hi guys, I assume this is old news, although I haven't seen anything
else mentioned on list since the chain Dirk started - there's a koji
build of 0.9 for rawhide, the source rpm of which contains a gmime 2.6
patch.  I recently moved from Ubuntu to Fedora 16 on the netbook so I
grabbed the patch and spec file, updated it to point to the 0.10 tarball
and can confirm that the patch still applies cleanly and the notmuch
build appears fine (crypto et al).

Assuming this mail sends, of course :-)


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


release-candidate/0.6

2011-05-07 Thread Darren McGuicken
On Fri, 06 May 2011 12:46:34 -0700, Jameson Graef Rollins  wrote:
> However, the current version of libgmime-2.4 in testing and unstable
> (2.4.23-1) unfortunately breaks signature verification, which means
> that many of the crypto tests will fail.  The issue has been fixed
> upstream, and we've been pushing on the libgmime maintainer to push a
> new release.  Hopefully a release of notmuch 0.6 into debian will put
> extra pressure on getting this issue resolved.

Another +1.  RC continues to work well (I've been running the crypto
branch since its creation), and I'm now using it with gmime-2.4.24.  No
issues with signature verification that I can see, including viewing
threads previously borked under gmime-2.4.14.

Thanks for this!
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



Re: release-candidate/0.6

2011-05-07 Thread Darren McGuicken
On Fri, 06 May 2011 12:46:34 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 However, the current version of libgmime-2.4 in testing and unstable
 (2.4.23-1) unfortunately breaks signature verification, which means
 that many of the crypto tests will fail.  The issue has been fixed
 upstream, and we've been pushing on the libgmime maintainer to push a
 new release.  Hopefully a release of notmuch 0.6 into debian will put
 extra pressure on getting this issue resolved.

Another +1.  RC continues to work well (I've been running the crypto
branch since its creation), and I'm now using it with gmime-2.4.24.  No
issues with signature verification that I can see, including viewing
threads previously borked under gmime-2.4.14.

Thanks for this!


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


[Review] Re: new "crypto" branch providing full PGP/MIME support

2011-02-27 Thread Darren McGuicken
On Sat, 26 Feb 2011 20:45:15 -0400, David Bremner  wrote:
> Further to our discussion on IRC the other day about providing
> feedback on patches, I have run these patches pretty much all of
> February with no glitches.  I am running them on 3 different machines,
> although they are all Debian AMD64 boxes.

If feedback is needed here then likewise, I've been running the crypto
branch since it was made available.  The only strangeness I've seen was
that which was reported in id:"87sjw2h6xy.fsf at bookbinder.fernseed.info"
for expired keys.

Even with that glitch, I really can't see me going back to vanilla
notmuch until these patches are pulled.  They're just ridiculously
useful.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



Org-mode support

2011-02-15 Thread Darren McGuicken
On Tue, 15 Feb 2011 08:40:06 +0100, Albin Stjerna  wrote:
> Here I'd like to call your attention to notmorg, [...]  it generates
> an agenda file containing all mails tagged ?todo?, with optionally
> generated scheduled/deadline tags. Of course, it could be updated to
> use your interaction code to link back to the actual notmuch emails.

This sounds really useful for the org junkies amongst us!  Sadly it
appears to be broken, at least when using Jamie's crypto branch.  Are
you running vanilla 0.5 with no problems?

If so, I'm guessing the reason may be that David's improved multipart
handling patch series changes the json output in a manner not handled by
the notmorg lisp since I'm seeing some output in my messages buffer
which begins with a line 'Wrong type argument: stringp, ((:content"',
then an email body, then ends with a line beginning '" :content-type
"text/plain"' and the list signature...

CC-ing Kristoffer, the maintainer.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



Re: Org-mode support

2011-02-15 Thread Darren McGuicken
On Tue, 15 Feb 2011 08:40:06 +0100, Albin Stjerna al...@eval.nu wrote:
 Here I'd like to call your attention to notmorg, [...]  it generates
 an agenda file containing all mails tagged »todo«, with optionally
 generated scheduled/deadline tags. Of course, it could be updated to
 use your interaction code to link back to the actual notmuch emails.

This sounds really useful for the org junkies amongst us!  Sadly it
appears to be broken, at least when using Jamie's crypto branch.  Are
you running vanilla 0.5 with no problems?

If so, I'm guessing the reason may be that David's improved multipart
handling patch series changes the json output in a manner not handled by
the notmorg lisp since I'm seeing some output in my messages buffer
which begins with a line 'Wrong type argument: stringp, ((:content',
then an email body, then ends with a line beginning ' :content-type
text/plain' and the list signature...

CC-ing Kristoffer, the maintainer.


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


Org-mode support

2011-02-13 Thread Darren McGuicken
On Mon, 07 Feb 2011 22:22:17 +0100, Matthieu Lemerre  wrote:
> I have written the org-mode support for notmuch a while ago. It allows
> to open links to notmuch from org-mode and create org-mode link from
> notmuch buffers.

Excellent, thanks for this, I'll check it out - how does this compare to
the org support for something like gnus?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



new "crypto" branch providing full PGP/MIME support

2011-02-05 Thread Darren McGuicken
On Fri, 04 Feb 2011 09:32:23 -0800, Jameson Rollins  wrote:
> Yeah, I've found some emails that are doing this as well.  I'm looking
> in to what we can do to mitigate the problem, which I think is
> ultimately a problem in GMime.  The json output should not be
> breaking, though, so that I will definitely fix.

I pulled your latest updates to the crypto branch (I can reply to
encrypted mails without resorting to Gnus!  W00t!) and have noticed that
I'm not seeing the json eof anymore, but if I grab the keys for the
various folks in this thread as a test (Micah seems to be signing with
an expired key?) then emacs just hangs when trying to produce the
notmuch-show buffer.

I can actually see the notmuch show process pegging the cpu in top.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



Re: new crypto branch providing full PGP/MIME support

2011-02-05 Thread Darren McGuicken
On Fri, 04 Feb 2011 09:32:23 -0800, Jameson Rollins 
jroll...@finestructure.net wrote:
 Yeah, I've found some emails that are doing this as well.  I'm looking
 in to what we can do to mitigate the problem, which I think is
 ultimately a problem in GMime.  The json output should not be
 breaking, though, so that I will definitely fix.

I pulled your latest updates to the crypto branch (I can reply to
encrypted mails without resorting to Gnus!  W00t!) and have noticed that
I'm not seeing the json eof anymore, but if I grab the keys for the
various folks in this thread as a test (Micah seems to be signing with
an expired key?) then emacs just hangs when trying to produce the
notmuch-show buffer.

I can actually see the notmuch show process pegging the cpu in top.


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


new "crypto" branch providing full PGP/MIME support

2011-02-04 Thread Darren McGuicken
On Thu, 03 Feb 2011 13:02:41 -0800, Jameson Rollins  wrote:
> > Can we pass the decrypted text to message mode on a reply?
> Yeah, some folks pointed this out on #notmuch this morning.  The
> decryption is only happening in notmuch-show, but we need to do it in
> notmuch-reply as well for the decrypted text to show up in the reply.
> I'm working on it now.

Great news, thanks!

Also: another confirmation for the revoked/expired key behaviour.  Emacs
UI just reports:

  json-read-string: Wrong type argument: characterp, :json-eof

Let me know if you need any samples of misbehaving mails.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



new "crypto" branch providing full PGP/MIME support

2011-02-03 Thread Darren McGuicken
On Wed, 02 Feb 2011 17:18:45 -0800, Jameson Rollins  wrote:
> Please test and provide feedback.  I would really like to see this
> series merged into the mainline for the next release, if at all
> possible.

Fan.  Tastic.  Thanks so much for this, incredible work!

Grabbed and testing now, the only slight niggle I see is that when I
reply to an encrypted mail I still get:

  On Thu, 03 Feb 2011 19:17:45 +, Someone  wrote:
  Non-text part: application/pgp-encrypted
  Non-text part: application/octet-stream

Can we pass the decrypted text to message mode on a reply?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



Re: new crypto branch providing full PGP/MIME support

2011-02-03 Thread Darren McGuicken
On Wed, 02 Feb 2011 17:18:45 -0800, Jameson Rollins 
jroll...@finestructure.net wrote:
 Please test and provide feedback.  I would really like to see this
 series merged into the mainline for the next release, if at all
 possible.

Fan.  Tastic.  Thanks so much for this, incredible work!

Grabbed and testing now, the only slight niggle I see is that when I
reply to an encrypted mail I still get:

  On Thu, 03 Feb 2011 19:17:45 +, Someone foo@bar wrote:
  Non-text part: application/pgp-encrypted
  Non-text part: application/octet-stream

Can we pass the decrypted text to message mode on a reply?


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


Bug in emacs showing long threads

2010-12-20 Thread Darren McGuicken
On Sun, 19 Dec 2010 22:27:05 -0500, Scott Henson  
wrote:
> I've been having problems with really long threads for a while when
> using notmuch.  When I click on them in emacs to display the content,
> I get "Lisp nesting exceeds `max-lisp-eval-depth'"

Hi Scott, have you tried just bumping up the value of
max-lisp-eval-depth from its default value?  I'm not sure that gets at
the root of the problem but it should at least make the threads
viewable.

Try adding to your .emacs, something like:
   (setq max-lisp-eval-depth 1000)

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



Re: Bug in emacs showing long threads

2010-12-20 Thread Darren McGuicken
On Sun, 19 Dec 2010 22:27:05 -0500, Scott Henson sc...@foolishpride.org wrote:
 I've been having problems with really long threads for a while when
 using notmuch.  When I click on them in emacs to display the content,
 I get Lisp nesting exceeds `max-lisp-eval-depth'

Hi Scott, have you tried just bumping up the value of
max-lisp-eval-depth from its default value?  I'm not sure that gets at
the root of the problem but it should at least make the threads
viewable.

Try adding to your .emacs, something like:
   (setq max-lisp-eval-depth 1000)



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


[PATCH] How to improve the mail handling workflow?

2010-11-13 Thread Darren McGuicken
On Sat, 13 Nov 2010 07:05:58 +0100, Michal Sojka  wrote:
> I agree with you in that in many cases tags can be replaced by saved
> searches. Last time I did it, i.e. used saved searches to distinguish
> messages from different mailing lists, the result was that it took
> very long time (something like 5 seconds) to show notmuch-hello

Interesting, what Xapian backend are you using?  I moved to chert after
id:"87ocl1lut1.fsf at yoom.home.cworth.org" and my notmuch-hello with 15
saved searches appears in a couple of seconds when freshly loaded,
faster when switching back to it after use.  That may well be slower
than just tag searches but it's not yet at a threshold where I notice
it.  How many searches had you saved?

> Additionally, I compared the speed of command line searches for tags
> and for the whole email addresses and even without the bug mentioned
> above, the search for to: is usually slower than the search for tag:.

Very non-scientifically just using time and vm/drop_caches on my
netbook, having tagged all mail sent to the list address with 'notmuch',
I seem to get much the same performance:

   $ time notmuch search tag:notmuch > /dev/null

   real0m21.074s
   user0m4.740s
   sys 0m1.916s

   $ time notmuch search to:notmuch > /dev/null

   real0m20.280s
   user0m4.600s
   sys 0m2.048s

   $ time notmuch search to:notmuch at notmuchmail.org > /dev/null

   real0m21.790s
   user0m5.044s
   sys 0m2.008s
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



[PATCH] How to improve the mail handling workflow?

2010-11-12 Thread Darren McGuicken
On Fri, 12 Nov 2010 17:35:22 +0100, Matthieu Lemerre  wrote:
> I prefer to add tags, for the following reasons:

It sounds like we do much the same things with our mail except that your
approach is quite disciplined and mine quite lazy :-)

>  - If I want to search through a mailing list, I don't have to
>  remember its address. Saved searchs solve the problem only partly,
>  because I am not able to make complex queries involving several saved
>  searches. This could be solved only by making notmuch aware of saved
>  searches.

[...]

> By default, hitting the space bar throughout a thread would remove
> every tag from the thread, so you keep asking "where was the mail in
> my inbox that I have read and I can't find anymore?"

As it's so quick, I tend to search my entire archive, even for new
messages, through progressive stages of filtering (which is really all
that a saved search is) starting off knowing only vaguely what it is
that I'm looking for.

For instance 'there was something on the notmuch list about printing
format issues recently' would be 's to:notmuch' 'f print' 'f format' etc
until I see what I'm looking for (or something similar) in the results.
That particular set of steps gives me a buffer with 24 threads in it,
the second of which is what I was looking for.  I tend not to even
bother with subject header based searches unless I know for sure that
what I'm looking for had an unusual subject.

It sounds like a lot of work when I write it out long-form, but it's
incredibly intuitive and so far always gets me what I need.

I can see your approach has its own merits though.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



[PATCH] How to improve the mail handling workflow?

2010-11-12 Thread Darren McGuicken
On Fri, 12 Nov 2010 16:23:58 +0100, Matthieu Lemerre  wrote:
> Here is first a patch that copes with this last point. Whenever you
> want to archive a thread, it finds whether you forgot to add a custom
> "user" tag to a message, and if so asks you for a tag to add before
> archiving. That way, I no longer have messages without any tags.

Hmm, this would be very irritating in my own workflow in which I really
only use a small number of tags on a fraction of my total mail archive
to differentiate mail type or content which can't otherwise be
determined from the indexed plain text of the message (I don't like to
add a 'notmuch' tag to mail from the list for instance since a saved
search for mail sent to the list address does exactly the same thing).

I agree that the spacebar does too much if you're just using a search on
the inbox tag and want something to stay visible even when you've
quickly spacebar'd through a thread and archived it, but in my case that
was easily solved by creating a new default saved search called 'todo'
which collects unread, manually tagged 'todo' and mail matching a number
of other criteria into one place.  When something has been followed-up
on, I remove the tag.

Colouring threads using notmuch-search-line-faces is also very useful in
that one-stop 'todo' view.

Would any of that work for you?  Why are plain text or header searches
not able to find the mail you're looking for?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



Re: [PATCH] How to improve the mail handling workflow?

2010-11-12 Thread Darren McGuicken
On Fri, 12 Nov 2010 16:23:58 +0100, Matthieu Lemerre ra...@free.fr wrote:
 Here is first a patch that copes with this last point. Whenever you
 want to archive a thread, it finds whether you forgot to add a custom
 user tag to a message, and if so asks you for a tag to add before
 archiving. That way, I no longer have messages without any tags.

Hmm, this would be very irritating in my own workflow in which I really
only use a small number of tags on a fraction of my total mail archive
to differentiate mail type or content which can't otherwise be
determined from the indexed plain text of the message (I don't like to
add a 'notmuch' tag to mail from the list for instance since a saved
search for mail sent to the list address does exactly the same thing).

I agree that the spacebar does too much if you're just using a search on
the inbox tag and want something to stay visible even when you've
quickly spacebar'd through a thread and archived it, but in my case that
was easily solved by creating a new default saved search called 'todo'
which collects unread, manually tagged 'todo' and mail matching a number
of other criteria into one place.  When something has been followed-up
on, I remove the tag.

Colouring threads using notmuch-search-line-faces is also very useful in
that one-stop 'todo' view.

Would any of that work for you?  Why are plain text or header searches
not able to find the mail you're looking for?


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


Re: [PATCH] How to improve the mail handling workflow?

2010-11-12 Thread Darren McGuicken
On Fri, 12 Nov 2010 17:35:22 +0100, Matthieu Lemerre ra...@free.fr wrote:
 I prefer to add tags, for the following reasons:

It sounds like we do much the same things with our mail except that your
approach is quite disciplined and mine quite lazy :-)

  - If I want to search through a mailing list, I don't have to
  remember its address. Saved searchs solve the problem only partly,
  because I am not able to make complex queries involving several saved
  searches. This could be solved only by making notmuch aware of saved
  searches.

[...]

 By default, hitting the space bar throughout a thread would remove
 every tag from the thread, so you keep asking where was the mail in
 my inbox that I have read and I can't find anymore?

As it's so quick, I tend to search my entire archive, even for new
messages, through progressive stages of filtering (which is really all
that a saved search is) starting off knowing only vaguely what it is
that I'm looking for.

For instance 'there was something on the notmuch list about printing
format issues recently' would be 's to:notmuch' 'f print' 'f format' etc
until I see what I'm looking for (or something similar) in the results.
That particular set of steps gives me a buffer with 24 threads in it,
the second of which is what I was looking for.  I tend not to even
bother with subject header based searches unless I know for sure that
what I'm looking for had an unusual subject.

It sounds like a lot of work when I write it out long-form, but it's
incredibly intuitive and so far always gets me what I need.

I can see your approach has its own merits though.


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


notmuch for documents

2010-11-07 Thread Darren McGuicken
On Sat, 06 Nov 2010 23:28:21 +, Darren McGuicken  wrote:
> I've now had a chance to play with this a little and while indexing,
> tagging and searching all seem to work as expected, I am getting the
> error 'Stack overflow in regexp matcher' when I try to view any of the
> ebooks which either leaves the buffer basically useless (no notmuch key
> shortcuts will work) or leads to a full segfault in emacs (23.1.1).

Hmm, looks like Michal's patch back in July fixes this behaviour:

 id:"1279279955-3110-1-git-send-email-sojkam1 at fel.cvut.cz"
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20101106/15b664f7/attachment.pgp>


notmuch for documents

2010-11-07 Thread Darren McGuicken
On Sat, 06 Nov 2010 16:12:17 -0400, Jameson Rollins  wrote:
> But that's it!  Everything else works as a perfect ebook indexer.  I
> can of course even add tags to my books.  Beautiful.  It's really
> quite incredible how well it works for this out of the box.  The only
> other issue is that my ebooks don't come in rfc5322-formatted files.
> I have to translate them for notmuch to work.

I've now had a chance to play with this a little and while indexing,
tagging and searching all seem to work as expected, I am getting the
error 'Stack overflow in regexp matcher' when I try to view any of the
ebooks which either leaves the buffer basically useless (no notmuch key
shortcuts will work) or leads to a full segfault in emacs (23.1.1).

The trace begins:

Debugger entered--Lisp error: (error "Stack overflow in regexp matcher")
  re-search-forward("\\(^[^>]+\\)\n>" nil t)
  notmuch-wash-tidy-citations(0)
  run-hook-with-args(notmuch-wash-tidy-citations 0)
  notmuch-show-insert-part-text/plain((:body ((:content "The Project
  Gutenberg EBook of The Adventures of Sherlock Holmes\nby Sir Art...

The contents of the ':content' part appears to be the complete text of
the novel.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



notmuch for documents

2010-11-06 Thread Darren McGuicken
On Sat, 06 Nov 2010 16:59:17 -0400, Jameson Rollins  wrote:
> Hey, Darren.  Total side note, but you might be interested in the recent
> message from Kristoffer about his nice rss2message utility, "sluk", that
> works great for translating rss feeds into notmuch-indexable messages:

Thanks for the heads up Jamie - I saw this come through but at the time
it didn't seem to support most of the feeds I was reading.  I didn't
look too closely since feed2imap worked for me.  I'll check out the
latest version and see if that has changed.  I do like the idea of
notmuch-to-feed as a companion tool.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



notmuch for documents

2010-11-06 Thread Darren McGuicken
On Sat, 06 Nov 2010 16:12:17 -0400, Jameson Rollins  wrote:
> Notmuch is the best damn mail system there ever was and we wouldn't
> want to mess with that.  Does abstracting everything in notmuch from
> "messages" -> "documents" hurt it as a mail system?  What if just the
> back-end were abstracted, to allow for different front-ends for
> different classes of documents, i.e. "messages", "articles", "books",
> "rss feeds", etc.?  Are there any big problems with this proposal that
> I'm overlooking?
> 
> I'm very interested to hear what others think about this idea.

Absolutely 100% in agreement - the reason I use emacs for everything I
possibly can from web browsing to writing to coding to mailing is
because it's all just (occasionally arbitrarily formatted) text and all
text can be dealt with across buffers in exactly the same manner.  The
ability to use a single indexer and search interface for any of that
same text gets a big +1 from me.

I recently started using feed2imap in order to get notmuch tagging and
searching for rss, I'm sure I'm not alone.  I was just wondering how on
earth to go about adding headers to my sets of org-mode formatted notes,
for instance, so that notmuch could pick them up and index them for me.

In fact, the less of a distinction between the types of 'document' I'm
dealing with the better.  Maybe different document types get different
default keybindings - I may not want to 'reply' to an ebook but I
absolutely may want to forward it to someone?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



Re: notmuch for documents

2010-11-06 Thread Darren McGuicken
On Sat, 06 Nov 2010 16:12:17 -0400, Jameson Rollins 
jroll...@finestructure.net wrote:
 But that's it!  Everything else works as a perfect ebook indexer.  I
 can of course even add tags to my books.  Beautiful.  It's really
 quite incredible how well it works for this out of the box.  The only
 other issue is that my ebooks don't come in rfc5322-formatted files.
 I have to translate them for notmuch to work.

I've now had a chance to play with this a little and while indexing,
tagging and searching all seem to work as expected, I am getting the
error 'Stack overflow in regexp matcher' when I try to view any of the
ebooks which either leaves the buffer basically useless (no notmuch key
shortcuts will work) or leads to a full segfault in emacs (23.1.1).

The trace begins:

Debugger entered--Lisp error: (error Stack overflow in regexp matcher)
  re-search-forward(\\(^[^]+\\)\n nil t)
  notmuch-wash-tidy-citations(0)
  run-hook-with-args(notmuch-wash-tidy-citations 0)
  notmuch-show-insert-part-text/plain((:body ((:content The Project
  Gutenberg EBook of The Adventures of Sherlock Holmes\nby Sir Art...

The contents of the ':content' part appears to be the complete text of
the novel.


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


Re: notmuch for documents

2010-11-06 Thread Darren McGuicken
On Sat, 06 Nov 2010 23:28:21 +, Darren McGuicken 
mailing-notm...@fernseed.info wrote:
 I've now had a chance to play with this a little and while indexing,
 tagging and searching all seem to work as expected, I am getting the
 error 'Stack overflow in regexp matcher' when I try to view any of the
 ebooks which either leaves the buffer basically useless (no notmuch key
 shortcuts will work) or leads to a full segfault in emacs (23.1.1).

Hmm, looks like Michal's patch back in July fixes this behaviour:

 id:1279279955-3110-1-git-send-email-sojk...@fel.cvut.cz


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


bug report: notmuch-hello 'All tags' view

2010-11-03 Thread Darren McGuicken
On Tue, 02 Nov 2010 17:33:08 -0400, Jameson Rollins  wrote:
> On Tue, 02 Nov 2010 21:03:55 +0000, Darren McGuicken  fernseed.info> wrote:
> > A call to 'notmuch search-tags' from the command line does indeed
> > return an empty string as the first entry for me[1].
> 
> fwiw, I don't personally get any empty strings in the output of
> search-tags (with 0.4).  So I don't think it's anything inherent to
> that function.

Thanks for the confirmation Jamie - I had a potter with my data and sure
enough, a search for 'tag:""' returned one hit.  I was able to use the
emacs interface to remove the empty string tag from the matching message
('-' then return with no parameters).

So it's probably fair to say that we'll want to handle at least the
empty string scenario as part of our standard tag addition logic since
it can lead to unexpected side effects in searching.

Do we have any other 'known bad' scenarios in tag addition that we want
to catch before I try my hand at a patch?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20101103/d599ca72/attachment.pgp>


Re: bug report: notmuch-hello 'All tags' view

2010-11-03 Thread Darren McGuicken
On Tue, 02 Nov 2010 17:33:08 -0400, Jameson Rollins 
jroll...@finestructure.net wrote:
 On Tue, 02 Nov 2010 21:03:55 +, Darren McGuicken 
 mailing-notm...@fernseed.info wrote:
  A call to 'notmuch search-tags' from the command line does indeed
  return an empty string as the first entry for me[1].
 
 fwiw, I don't personally get any empty strings in the output of
 search-tags (with 0.4).  So I don't think it's anything inherent to
 that function.

Thanks for the confirmation Jamie - I had a potter with my data and sure
enough, a search for 'tag:' returned one hit.  I was able to use the
emacs interface to remove the empty string tag from the matching message
('-' then return with no parameters).

So it's probably fair to say that we'll want to handle at least the
empty string scenario as part of our standard tag addition logic since
it can lead to unexpected side effects in searching.

Do we have any other 'known bad' scenarios in tag addition that we want
to catch before I try my hand at a patch?


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


bug report: notmuch-hello 'All tags' view

2010-11-02 Thread Darren McGuicken
On Tue, 02 Nov 2010 20:17:56 +, Darren McGuicken  wrote:
> I've noticed since rebasing to 0.4 that I'm seeing an empty entry in the
> 'All tags' view of notmuch-hello which appears to represent a search
> against 'tag:'.  

Continuing what's turning into an epic one-man list-noise generation
effort, I did a bit more digging and it looks like notmuch-hello
generates the list of tags for the 'All tags' view by processing each
line returned by 'search-tags'.

A call to 'notmuch search-tags' from the command line does indeed return
an empty string as the first entry for me[1].

Does that point to bad data on my part, or has the output of
'search-tags' changed recently?

If the former, any thoughts on how I differentiate an empty tag from
something untagged in a search so I can prune it?


[1] So we have an apparently empty tag being concatenated with a search
string of 'tag:', which actually gives us a search for every message
containing the word 'tag' rather than a tag-based search.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20101102/4b8df5ef/attachment.pgp>


bug report: notmuch-hello 'All tags' view

2010-11-02 Thread Darren McGuicken
Wow, that was probably the most secure bug report in history - this time
in plain for those of you who don't have access to Carl's private key!

I've noticed since rebasing to 0.4 that I'm seeing an empty entry in the
'All tags' view of notmuch-hello which appears to represent a search
against 'tag:'.  

For some reason this search matches 1,233 of my now 22,905 messages,
encompassing a date range of about five years and including an
apparently random collection of both tagged and untagged threads.

Anyone else seeing anything similar?  What else do you need from me to
track this one down?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



***UNCHECKED*** bug report: notmuch-hello 'All tags' view

2010-11-02 Thread Darren McGuicken
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-encrypted
Size: 11 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/octet-stream
Size: 1729 bytes
Desc: not available
URL: 



Re: bug report: notmuch-hello 'All tags' view

2010-11-02 Thread Darren McGuicken
Wow, that was probably the most secure bug report in history - this time
in plain for those of you who don't have access to Carl's private key!

I've noticed since rebasing to 0.4 that I'm seeing an empty entry in the
'All tags' view of notmuch-hello which appears to represent a search
against 'tag:'.  

For some reason this search matches 1,233 of my now 22,905 messages,
encompassing a date range of about five years and including an
apparently random collection of both tagged and untagged threads.

Anyone else seeing anything similar?  What else do you need from me to
track this one down?


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


Re: bug report: notmuch-hello 'All tags' view

2010-11-02 Thread Darren McGuicken
On Tue, 02 Nov 2010 20:17:56 +, Darren McGuicken 
mailing-notm...@fernseed.info wrote:
 I've noticed since rebasing to 0.4 that I'm seeing an empty entry in the
 'All tags' view of notmuch-hello which appears to represent a search
 against 'tag:'.  

Continuing what's turning into an epic one-man list-noise generation
effort, I did a bit more digging and it looks like notmuch-hello
generates the list of tags for the 'All tags' view by processing each
line returned by 'search-tags'.

A call to 'notmuch search-tags' from the command line does indeed return
an empty string as the first entry for me[1].

Does that point to bad data on my part, or has the output of
'search-tags' changed recently?

If the former, any thoughts on how I differentiate an empty tag from
something untagged in a search so I can prune it?


[1] So we have an apparently empty tag being concatenated with a search
string of 'tag:', which actually gives us a search for every message
containing the word 'tag' rather than a tag-based search.


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


Kudos! Also: +1 PGP!

2010-04-26 Thread Darren McGuicken
On Mon, 26 Apr 2010 07:16:16 -0400, Jameson Rollins  wrote:
> > In the meantime, I find myself using the snippet from Tassilo in:
> > id:87zl6cl595.fsf at thinkpad.tsdh.de
> 
> I'm interested in using this as a stop-gap, but unfortunately I'm not
> finding this message in my local store.  Can you point to url in an
> archive, or forward this to me or the list?

Absolutely, you can find the thread on gmane here:

 http://thread.gmane.org/gmane.mail.notmuch.general/778/focus=78

One other thing I'd recommend is downloading the complete archive from
the link on notmuchmail.org:

 http://notmuchmail.org/archives/notmuch.mbox

It's incredibly handy being able to search for notmuch information with
notmuch itself!
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



Re: Kudos! Also: +1 PGP!

2010-04-26 Thread Darren McGuicken
On Mon, 26 Apr 2010 07:16:16 -0400, Jameson Rollins 
jroll...@finestructure.net wrote:
  In the meantime, I find myself using the snippet from Tassilo in:
  id:87zl6cl595@thinkpad.tsdh.de
 
 I'm interested in using this as a stop-gap, but unfortunately I'm not
 finding this message in my local store.  Can you point to url in an
 archive, or forward this to me or the list?

Absolutely, you can find the thread on gmane here:

 http://thread.gmane.org/gmane.mail.notmuch.general/778/focus=78

One other thing I'd recommend is downloading the complete archive from
the link on notmuchmail.org:

 http://notmuchmail.org/archives/notmuch.mbox

It's incredibly handy being able to search for notmuch information with
notmuch itself!


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


Kudos! Also: +1 PGP!

2010-04-25 Thread Darren McGuicken
I just wanted to drop a quick mail to the list to give you all my huge
thanks for this already astonishingly useful tool!  

Like a few others, it seems, I arrived here after reading a
not-very-grumpy review in the Grumpy Editor series[1].
Everything-is-a-search combined with CLI access?!  Sold!

I've been slowly moving all my day-to-day mailing needs to notmuch over
the last month and the only thing I'm missing is native message
decryption and verification support - is this being actively worked on,
I haven't seen it mentioned in a while?  Or is it feasible to add this
as a target for an upcoming merge window?  How far away are we from
something workable - are we just(!) looking for someone to stitch the
code together or do we need to brainstorm a little more exactly what the
approach is likely to be?

In the meantime, I find myself using the snippet from Tassilo in:

id:87zl6cl595.fsf at thinkpad.tsdh.de

Which lets me jump to the selected encrypted message in Gnus and have it
in turn auto-decrypt the text.  Works well but does need a second mail
program ;-)


[1] http://lwn.net/Articles/380073/
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



Kudos! Also: +1 PGP!

2010-04-25 Thread Darren McGuicken
I just wanted to drop a quick mail to the list to give you all my huge
thanks for this already astonishingly useful tool!  

Like a few others, it seems, I arrived here after reading a
not-very-grumpy review in the Grumpy Editor series[1].
Everything-is-a-search combined with CLI access?!  Sold!

I've been slowly moving all my day-to-day mailing needs to notmuch over
the last month and the only thing I'm missing is native message
decryption and verification support - is this being actively worked on,
I haven't seen it mentioned in a while?  Or is it feasible to add this
as a target for an upcoming merge window?  How far away are we from
something workable - are we just(!) looking for someone to stitch the
code together or do we need to brainstorm a little more exactly what the
approach is likely to be?

In the meantime, I find myself using the snippet from Tassilo in:

id:87zl6cl595@thinkpad.tsdh.de

Which lets me jump to the selected encrypted message in Gnus and have it
in turn auto-decrypt the text.  Works well but does need a second mail
program ;-)


[1] http://lwn.net/Articles/380073/


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