[PATCH] use custom-face-edit value-type in notmuch-search-line-faces

[Jameson Rollins]

On Sat, 26 Mar 2011 22:16:32 -0700, Jameson Graef Rollins  wrote:
> This enables the proper face customization UI for
> notmuch-search-line-faces.

Hey, folks.  amdragon was the one who figured out that custom-face-edit
was the correct value-type to use to get the face customization ui for
the notmuch-search-line-faces list.  However, he seems to think this
might not be the right solution.  Austin: care to comment?

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

Re: [PATCH] use custom-face-edit value-type in notmuch-search-line-faces

[Jameson Rollins]

On Sat, 26 Mar 2011 22:16:32 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 This enables the proper face customization UI for
 notmuch-search-line-faces.

Hey, folks.  amdragon was the one who figured out that custom-face-edit
was the correct value-type to use to get the face customization ui for
the notmuch-search-line-faces list.  However, he seems to think this
might not be the right solution.  Austin: care to comment?

jamie.


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

problem with folder: search in python bindings

[Jameson Rollins]

On Tue, 22 Mar 2011 10:35:17 +0100, Sebastian Spaeth  
wrote:
> Pfeww, I was getting very scared that the python bindings have serious
> flaws that I am not aware of. Don't ever do that again to me :-).

In the future, we should make sure that all new features are included
since the beginning.  That way we'll avoid all future library
incompatibilities.

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

Re: problem with folder: search in python bindings

[Jameson Rollins]

On Tue, 22 Mar 2011 10:35:17 +0100, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 Pfeww, I was getting very scared that the python bindings have serious
 flaws that I am not aware of. Don't ever do that again to me :-).

In the future, we should make sure that all new features are included
since the beginning.  That way we'll avoid all future library
incompatibilities.

jamie.


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

problem with folder: search in python bindings

[Jameson Rollins]

On Mon, 21 Mar 2011 13:42:09 -0400, Jesse Rosenthal  
wrote:
> On Mon, 21 Mar 2011 10:34:29 -0700, Jameson Rollins  finestructure.net> wrote:
> > It's going to take a lot more digging before I can identify what is
> > common about these messages and different from all the messages that are
> > not returned.  
> 
> One guess: do those messages happen to have "folder:sent" in the
> body? If so, that might point to the possibility that the python
> bindings are using a different libnotmuch. Perhaps they have a different
> search path (and maybe there's a debian installed library around that
> they're finding?).

Oh good call, Jesse.  Bonus points for you!  That was the problem.  Damn
it.  In retrospect that's so obvious, though, isn't it!  I had purged
the notmuch binary package, but had accidentally left libnotmuch1 and
libnotmuch-dev installed.  Removing those packages and pointing to my
locally installed libraries fixed the problem.

Sorry for spamming the list with what, in retrospect, I should have been
able to figure out on my own.  Thanks again, Jesse.

jamie.
-- 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/20110321/c60f0639/attachment.pgp>

problem with folder: search in python bindings

[Jameson Rollins]

On Mon, 21 Mar 2011 12:45:06 -0400, Jesse Rosenthal  
wrote:
> One thing to try would be to run it step by step in an interactive session. 
> I.e.,

Hey, Jesse.  So I'm getting different results interactively!:

>>> import notmuch
>>> db = notmuch.Database("/home/jrollins/.mail")
>>> query = notmuch.Query(db, "folder:sent")
>>> query.count_messages()
9L
>>> len(query.search_messages())
9
>>> 

This same search returns 635 results with the binary, 7 results with the
notmuch.py script, and now 9 in this interactive session.  This is going
to be a pain to debug.

> >>> msgs = [m for m in qry.search_messages()]
> 
> and take a look at them. Anything special about those messages?

So I'm seeing quite a few strange things here.

>>> for m in msgs:
... print m.get_message_id()
... print ' ', m.get_filename()
... 
87tyewtobx.fsf at gogo.home
  
/home/jrollins/.mail/mailboxes/snapper/new/1300725908.Vfd05I469d8M318600.snapper
871v20bfij.fsf at servo.finestructure.net
  
/home/jrollins/.mail/mailboxes/snapper/new/1300725184.Vfd05I469d6M959989.snapper
87y64dk9da.fsf at servo.finestructure.net
  
/home/jrollins/.mail/mailboxes/snapper/new/1300378797.Vfd05I469d8M808571.snapper
87aagv2z92.fsf at SSpaeth.de
  
/home/jrollins/.mail/mailboxes/snapper/new/1300267540.Vfd05I46a17M964837.snapper
87tyf4xmm1.fsf at servo.finestructure.net
  
/home/jrollins/.mail/mailboxes/snapper/new/1300213852.Vfd05I469d8M923454.snapper
1290682750-30283-3-git-send-email-dme at dme.org
  
/home/jrollins/.mail/archive/2010/cur/1290698042_0.5764.servo,U=333629,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
8763426kd5.fsf at steelpick.2x.cz
  
/home/jrollins/.mail/archive/2010/cur/1270740662_1.29713.servo,U=264838,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
87636feg10.fsf at servo.finestructure.net
  /home/jrollins/.mail/archive/2010/cur/1265129567.M505745P5400Q1.servo:2,S
87eil3ehjh.fsf at servo.finestructure.net
  /home/jrollins/.mail/archive/2010/cur/1265127608.M500761P12582Q1.servo:2,S
>>> 

First of all, only messages that were sent by me are in my sent folder.
There are no messages in there that are sent by anyone else.  But this
search is returning messages that are from people other than me.  That
makes no sense.

Second, strangely, all of the messages are ones that are sent to the
notmuch list.  Not sure what to make of that except that the messages
that were sent from me to the list are also in my received mail so are
actually duplicated in my mail store.  I have plenty of other messages
that fall into that same condition, though.

It's going to take a lot more digging before I can identify what is
common about these messages and different from all the messages that are
not returned.  For what it's worth, it's not *just* that they were sent
to the list, since the binary is counting 35 messages that are in the
sent folder and sent to the list:

servo:~ 0$ notmuch count folder:sent and to:notmuch
35
servo:~ 0$ 

I'll keep poking at this, but others can test this and report what they
see I would really appreciate it.

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

problem with folder: search in python bindings

[Jameson Rollins]

On Mon, 21 Mar 2011 16:29:57 +0100, Sebastian Spaeth  
wrote:
> On Thu, 17 Mar 2011 09:19:29 -0700, Jameson Rollins  finestructure.net> wrote:
> > Hey, Sebastian.  Can you share your notmuch.py script?
> 
> No, it's my secret plan for earning my pension :).
> You already got it:
> http://git.notmuchmail.org/git/notmuch/blob/HEAD:/bindings/python/notmuch.py

Thanks, Sebastian.  Very convenient of you to include it in the repo!

> Let me know what you find out.

So right off the bat I'm seeing a big discrepancy between the results

Re: problem with folder: search in python bindings

[Jameson Rollins]

On Mon, 21 Mar 2011 12:45:06 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote:
 One thing to try would be to run it step by step in an interactive session. 
 I.e.,

Hey, Jesse.  So I'm getting different results interactively!:

 import notmuch
 db = notmuch.Database(/home/jrollins/.mail)
 query = notmuch.Query(db, folder:sent)
 query.count_messages()
9L
 len(query.search_messages())
9
 

This same search returns 635 results with the binary, 7 results with the
notmuch.py script, and now 9 in this interactive session.  This is going
to be a pain to debug.

  msgs = [m for m in qry.search_messages()]
 
 and take a look at them. Anything special about those messages?

So I'm seeing quite a few strange things here.

 for m in msgs:
... print m.get_message_id()
... print ' ', m.get_filename()
... 
87tyewtobx@gogo.home
  
/home/jrollins/.mail/mailboxes/snapper/new/1300725908.Vfd05I469d8M318600.snapper
871v20bfij@servo.finestructure.net
  
/home/jrollins/.mail/mailboxes/snapper/new/1300725184.Vfd05I469d6M959989.snapper
87y64dk9da@servo.finestructure.net
  
/home/jrollins/.mail/mailboxes/snapper/new/1300378797.Vfd05I469d8M808571.snapper
87aagv2z92@sspaeth.de
  
/home/jrollins/.mail/mailboxes/snapper/new/1300267540.Vfd05I46a17M964837.snapper
87tyf4xmm1@servo.finestructure.net
  
/home/jrollins/.mail/mailboxes/snapper/new/1300213852.Vfd05I469d8M923454.snapper
1290682750-30283-3-git-send-email-...@dme.org
  
/home/jrollins/.mail/archive/2010/cur/1290698042_0.5764.servo,U=333629,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
8763426kd5@steelpick.2x.cz
  
/home/jrollins/.mail/archive/2010/cur/1270740662_1.29713.servo,U=264838,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
87636feg10@servo.finestructure.net
  /home/jrollins/.mail/archive/2010/cur/1265129567.M505745P5400Q1.servo:2,S
87eil3ehjh@servo.finestructure.net
  /home/jrollins/.mail/archive/2010/cur/1265127608.M500761P12582Q1.servo:2,S
 

First of all, only messages that were sent by me are in my sent folder.
There are no messages in there that are sent by anyone else.  But this
search is returning messages that are from people other than me.  That
makes no sense.

Second, strangely, all of the messages are ones that are sent to the
notmuch list.  Not sure what to make of that except that the messages
that were sent from me to the list are also in my received mail so are
actually duplicated in my mail store.  I have plenty of other messages
that fall into that same condition, though.

It's going to take a lot more digging before I can identify what is
common about these messages and different from all the messages that are
not returned.  For what it's worth, it's not *just* that they were sent
to the list, since the binary is counting 35 messages that are in the
sent folder and sent to the list:

servo:~ 0$ notmuch count folder:sent and to:notmuch
35
servo:~ 0$ 

I'll keep poking at this, but others can test this and report what they
see I would really appreciate it.

jamie.


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

Re: problem with folder: search in python bindings

[Jameson Rollins]

On Mon, 21 Mar 2011 13:42:09 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote:
 On Mon, 21 Mar 2011 10:34:29 -0700, Jameson Rollins 
 jroll...@finestructure.net wrote:
  It's going to take a lot more digging before I can identify what is
  common about these messages and different from all the messages that are
  not returned.  
 
 One guess: do those messages happen to have folder:sent in the
 body? If so, that might point to the possibility that the python
 bindings are using a different libnotmuch. Perhaps they have a different
 search path (and maybe there's a debian installed library around that
 they're finding?).

Oh good call, Jesse.  Bonus points for you!  That was the problem.  Damn
it.  In retrospect that's so obvious, though, isn't it!  I had purged
the notmuch binary package, but had accidentally left libnotmuch1 and
libnotmuch-dev installed.  Removing those packages and pointing to my
locally installed libraries fixed the problem.

Sorry for spamming the list with what, in retrospect, I should have been
able to figure out on my own.  Thanks again, Jesse.

jamie.


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

problem with folder: search in python bindings

[Jameson Rollins]

On Wed, 16 Mar 2011 10:25:29 +0100, Sebastian Spaeth  
wrote:
> Interesting, this is not at all what I am seeing in the current
> bindings:
> 
> cd ~/src/notmuch/bindings/python;./notmuch.py count 'folder:sent'
> 1957
> /usr/local/bin/notmuch count  'folder:sent'
> 1957

Hey, Sebastian.  Can you share your notmuch.py script?  I want to
compare yours with what I'm doing in my python script.  I don't think
it's a quoting issue, since the quoting I'm using seems to work fine for
other search terms.  It's only with "folder:" searches that I'm seeing
the problem.

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

Re: problem with folder: search in python bindings

[Jameson Rollins]

On Wed, 16 Mar 2011 10:25:29 +0100, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 Interesting, this is not at all what I am seeing in the current
 bindings:
 
 cd ~/src/notmuch/bindings/python;./notmuch.py count 'folder:sent'
 1957
 /usr/local/bin/notmuch count  'folder:sent'
 1957

Hey, Sebastian.  Can you share your notmuch.py script?  I want to
compare yours with what I'm doing in my python script.  I don't think
it's a quoting issue, since the quoting I'm using seems to work fine for
other search terms.  It's only with folder: searches that I'm seeing
the problem.

jamie.


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

python documentation

[Jameson Rollins]

On Tue, 15 Mar 2011 14:22:55 -0400, James Vasile  
wrote:
> notmuch dump includes '# TODO: implement "dump "' but it
> appears to work already.  What's missing?

Hey, James.  Is this related to the python documentation somehow?  If
so, I'm not sure how.

If you're just referencing a completed TODO, you could definitely submit
a patch to remove it from the TODO.

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

problem with folder: search in python bindings

[Jameson Rollins]

Hey, folks.  I'm seeing something peculiar with the python bindings.
It seems that I am not able to get any results when doing "folder:"
searches with the python bindings.  I'm using a version of notmuch that
includes the folder index patch.

Attached is a script that demonstrates the problem.  It generates a test
repository, then does a couple of searches over it.  When running the
script, I get the following output:

0$ ./python-folder-search-test
Found 2 total files (that's not much mail).
Note: Ignoring non-mail file: /home/jrollins/tmp/tmp.1dMO5vnweJ/config
Processed 2 total files in almost no time.
Added 1 new message to the database.
== notmuch search '*':
thread:0001  Yest. 23:26 [1/1] Jameson Rollins; python 
documentation (inbox signed unread)
== notmuch search 'folder:sent':
thread:0001  Yest. 23:26 [1/1] Jameson Rollins; python 
documentation (inbox signed unread)
== python search '*':
Jameson Rollins  (2011-03-14) (inbox signed 
unread) (-1) replies
== python search 'folder:sent':
0$ 

You can see that cli notmuch returns search results when searching for
"folder:sent".  The python bindings, on the other hand, return nothing.

Anyone have any idea what could be going on here?  I'm not familiar with
how the python bindings work, unfortunately.

jamie.

-- next part --
A non-text attachment was scrubbed...
Name: python-folder-search
Type: application/octet-stream
Size: 741 bytes
Desc: script to test python folder: search
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110315/55674a0b/attachment.obj>
-- 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/20110315/55674a0b/attachment.pgp>

python documentation

[Jameson Rollins]

I just discovered this:

http://packages.python.org/notmuch/

I don't know who did this, but THANK YOU!!  I want to buy you a beer.

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

problem with folder: search in python bindings

[Jameson Rollins]

Hey, folks.  I'm seeing something peculiar with the python bindings.
It seems that I am not able to get any results when doing folder:
searches with the python bindings.  I'm using a version of notmuch that
includes the folder index patch.

Attached is a script that demonstrates the problem.  It generates a test
repository, then does a couple of searches over it.  When running the
script, I get the following output:

0$ ./python-folder-search-test
Found 2 total files (that's not much mail).
Note: Ignoring non-mail file: /home/jrollins/tmp/tmp.1dMO5vnweJ/config
Processed 2 total files in almost no time.
Added 1 new message to the database.
== notmuch search '*':
thread:0001  Yest. 23:26 [1/1] Jameson Rollins; python 
documentation (inbox signed unread)
== notmuch search 'folder:sent':
thread:0001  Yest. 23:26 [1/1] Jameson Rollins; python 
documentation (inbox signed unread)
== python search '*':
Jameson Rollins jroll...@finestructure.net (2011-03-14) (inbox signed unread) 
(-1) replies
== python search 'folder:sent':
0$ 

You can see that cli notmuch returns search results when searching for
folder:sent.  The python bindings, on the other hand, return nothing.

Anyone have any idea what could be going on here?  I'm not familiar with
how the python bindings work, unfortunately.

jamie.



python-folder-search
Description: script to test python folder: search


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

Re: python documentation

[Jameson Rollins]

On Tue, 15 Mar 2011 14:22:55 -0400, James Vasile ja...@hackervisions.org 
wrote:
 notmuch dump includes '# TODO: implement dump filename' but it
 appears to work already.  What's missing?

Hey, James.  Is this related to the python documentation somehow?  If
so, I'm not sure how.

If you're just referencing a completed TODO, you could definitely submit
a patch to remove it from the TODO.

jamie.


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

Xapian locking errors with custom query parser

[Jameson Rollins]

> What do you think?
> 
> Of course, I still want to have email so that everyone can follow along
> at home, and it's easy to reply for patch review, etc.

Hey, Carl.  I would say you should just wait for an email to the list
that says explicitly that "branch X at remote Y is ready to be merged".
I feel like that would be most analogous to the sending of patches
directly to the list.  It's also less work for you, since you wouldn't
have to go around fishing for branches to merge.  And the more we can
reduce your work load the better!

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

Backtrace with latest crypto branch

[Jameson Rollins]

On Wed, 09 Mar 2011 22:14:55 +0100, Xavier Maillard  wrote:
> I did update and restarted emacs, yes. 
> Pressing RET on any message failed with the given backtrace. It also
> just displays headers but nothing about the content which is just
> trashed away (in the backtrace); any child message is also just trashed.

Hey, Xavier.  Let's go back a step.  Do you see the same problem when
you view the message from the command line?  Try:

notmuch show --format=json --verify id:87ei6h41s6.fsf at servo.finestructure.net

Do you see the body of the message ok in the json output?

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

Re: Backtrace with latest crypto branch

[Jameson Rollins]

On Wed, 09 Mar 2011 22:14:55 +0100, Xavier Maillard x...@gnu.org wrote:
 I did update and restarted emacs, yes. 
 Pressing RET on any message failed with the given backtrace. It also
 just displays headers but nothing about the content which is just
 trashed away (in the backtrace); any child message is also just trashed.

Hey, Xavier.  Let's go back a step.  Do you see the same problem when
you view the message from the command line?  Try:

notmuch show --format=json --verify id:87ei6h41s6@servo.finestructure.net

Do you see the body of the message ok in the json output?

jamie.


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

change of crypto mime customization variable

[Jameson Rollins]

On Mon, 07 Mar 2011 22:32:42 +0100, Xavier Maillard  
wrote:
> On Sat, 05 Mar 2011 16:10:06 -0800, Jameson Rollins  finestructure.net> wrote:
> > Hey, folks.  I just wanted to give all the crypto early adopters a heads
> > up that I just changed the crypto customization variable name in my
> > crypto branch to be:
> 
> Not sure if is related to these changes but your latest email did not
> show at all with crypto branch. I had to switch back with the main
> branch.

Hi, Xavier.  Do you mean that you rebuilt your installation of the
crypto branch after I made the change to the config variable, and
restarted emacs, and the message did not display the crypto header?  If
so, then yes, that's what is expected.  You have to now set the
"notmuch-process-crypto-mime" customization variable to see the crypto
headers.

jamie.
-- 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/20110307/377ed950/attachment.pgp>

Re: change of crypto mime customization variable

[Jameson Rollins]

On Mon, 07 Mar 2011 22:32:42 +0100, Xavier Maillard xav...@maillard.im wrote:
 On Sat, 05 Mar 2011 16:10:06 -0800, Jameson Rollins 
 jroll...@finestructure.net wrote:
  Hey, folks.  I just wanted to give all the crypto early adopters a heads
  up that I just changed the crypto customization variable name in my
  crypto branch to be:
 
 Not sure if is related to these changes but your latest email did not
 show at all with crypto branch. I had to switch back with the main
 branch.

Hi, Xavier.  Do you mean that you rebuilt your installation of the
crypto branch after I made the change to the config variable, and
restarted emacs, and the message did not display the crypto header?  If
so, then yes, that's what is expected.  You have to now set the
notmuch-process-crypto-mime customization variable to see the crypto
headers.

jamie.


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

signed/encrypted tagging in crypto branch

[Jameson Rollins]

On Sat, 05 Mar 2011 00:26:46 -0800, Jameson Rollins  wrote:
> Hey, folks.  I just pushed a couple of patches to my "crypto" branch [0]
> that add support for auto-tagging of multipart/signed and
> multipart/encrypted messages with the "signed" and "encrypted" tags
> respectively.  Only new messages are thus tagged, so a database rebuild
> is required to auto-tag old messages.

So I realized last night, what now seems obvious, that restoring tags
after a notmuch new will override any initial auto tagging.  This means
that doing a database rebuild will *not* crypto tag all your old mail if
you then restore tags from a tag dump afterwords.

I'm not sure if there's anything that can be done about this.  I think
we either have to have a way to merge tags, or the signed and encrypted
indicators need to exist in a different field in the database.  Tags
allow more flexibility in the UIs, but maybe we could just tag based on
a the new database field somehow?

It's not such a big deal that we only get "signed" and "encrypted" from
here forward, but it would be nice to re-tag old messages this way.  I
can imagine that something like this will come up again in the future,
and it would be nice if we had a solution.  I'm open to suggestions.

jamie.
-- 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/20110306/74b96cc6/attachment.pgp>

Re: signed/encrypted tagging in crypto branch

[Jameson Rollins]

On Sat, 05 Mar 2011 00:26:46 -0800, Jameson Rollins 
jroll...@finestructure.net wrote:
 Hey, folks.  I just pushed a couple of patches to my crypto branch [0]
 that add support for auto-tagging of multipart/signed and
 multipart/encrypted messages with the signed and encrypted tags
 respectively.  Only new messages are thus tagged, so a database rebuild
 is required to auto-tag old messages.

So I realized last night, what now seems obvious, that restoring tags
after a notmuch new will override any initial auto tagging.  This means
that doing a database rebuild will *not* crypto tag all your old mail if
you then restore tags from a tag dump afterwords.

I'm not sure if there's anything that can be done about this.  I think
we either have to have a way to merge tags, or the signed and encrypted
indicators need to exist in a different field in the database.  Tags
allow more flexibility in the UIs, but maybe we could just tag based on
a the new database field somehow?

It's not such a big deal that we only get signed and encrypted from
here forward, but it would be nice to re-tag old messages this way.  I
can imagine that something like this will come up again in the future,
and it would be nice if we had a solution.  I'm open to suggestions.

jamie.


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

change of crypto mime customization variable

[Jameson Rollins]

Hey, folks.  I just wanted to give all the crypto early adopters a heads
up that I just changed the crypto customization variable name in my
crypto branch to be:

  notmuch-process-crypto-mime

Daniel Gillmor has been doing a lot of great work with GMIME upstream to
include support for handling s/mime parts with the same crypto context.
When this work gets finished, pgp/mime and s/mime parts will both be
processed with the same crypto hooks.  Looking ahead, I thought the
previous variable name (notmuch-process-pgpmime) was overly specific.
And I wanted to get this change in before cworth's rumored imminent next
release push (waiting with bated breath!).

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

signed/encrypted tagging in crypto branch [was: Re: [Review] Re: new "crypto" branch providing full PGP/MIME support]

[Jameson Rollins]

Hey, folks.  I just pushed a couple of patches to my "crypto" branch [0]
that add support for auto-tagging of multipart/signed and
multipart/encrypted messages with the "signed" and "encrypted" tags
respectively.  Only new messages are thus tagged, so a database rebuild
is required to auto-tag old messages.

To be clear, after the previous discussion, these tags indicate nothing
about the validity of signatures or the decryptability of encrypted
messages.  They only indicate that a message contains a signed or
encrypted part according to the self-declared mime type.

This certainly makes it easier to find crypto messages, and it should
allow people to highlight signed or encrypted messages in the search
output using the "notmuch-search-lines-faces" customization variable
[1].

jamie.

[0] git://finestructure.net/notmuch
[1] The notmuch-search-lines-faces variable needs to be rewritten to
allow for full face customization support, but it also needs to continue
to specify a tag/face mapping.  Any elisp experts out there have any
good suggestions how to fix this?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

signed/encrypted tagging in crypto branch [was: Re: [Review] Re: new crypto branch providing full PGP/MIME support]

[Jameson Rollins]

Hey, folks.  I just pushed a couple of patches to my crypto branch [0]
that add support for auto-tagging of multipart/signed and
multipart/encrypted messages with the signed and encrypted tags
respectively.  Only new messages are thus tagged, so a database rebuild
is required to auto-tag old messages.

To be clear, after the previous discussion, these tags indicate nothing
about the validity of signatures or the decryptability of encrypted
messages.  They only indicate that a message contains a signed or
encrypted part according to the self-declared mime type.

This certainly makes it easier to find crypto messages, and it should
allow people to highlight signed or encrypted messages in the search
output using the notmuch-search-lines-faces customization variable
[1].

jamie.

[0] git://finestructure.net/notmuch
[1] The notmuch-search-lines-faces variable needs to be rewritten to
allow for full face customization support, but it also needs to continue
to specify a tag/face mapping.  Any elisp experts out there have any
good suggestions how to fix this?


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

change of crypto mime customization variable

[Jameson Rollins]

Hey, folks.  I just wanted to give all the crypto early adopters a heads
up that I just changed the crypto customization variable name in my
crypto branch to be:

  notmuch-process-crypto-mime

Daniel Gillmor has been doing a lot of great work with GMIME upstream to
include support for handling s/mime parts with the same crypto context.
When this work gets finished, pgp/mime and s/mime parts will both be
processed with the same crypto hooks.  Looking ahead, I thought the
previous variable name (notmuch-process-pgpmime) was overly specific.
And I wanted to get this change in before cworth's rumored imminent next
release push (waiting with bated breath!).

jamie.


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

Strange match to my query

[Jameson Rollins]

On Tue, 1 Mar 2011 16:00:51 -0700, Mark Anderson  
wrote:
> On Fri, 25 Feb 2011 15:29:05 -0600, Jameson Rollins  finestructure.net> wrote:
> > So I am in fact still seeing this bug, although I am ostensibly using a
> > version that includes the patch to fix it (db70f3f0).  Does this fix
> > require rebuilding the database?
> 
> Yes.
>
> The termlist is constructed when the message is added to the database,
> so the database must be reconstructed.
> 
> Newer messages will index email addresses so that they can't be matched
> by overlapping term indexes.  However, the corpus of your database is
> not going to change without manual intervention.

Ok, that's what I thought.  Thanks for the feedback, Mark.

> A simple rebuild when you go to bed can look like:

I think you're missing an important step:

notmuch dump >dump.txt
mv $(notmuch config get database.path){,.bak}
notmuch new
notmuch restore dump.txt

but I get the idea ;)

Thanks again.

jamie.
-- 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/20110301/7e7c3be2/attachment.pgp>

Make MBox

[Jameson Rollins]

On Tue, 01 Mar 2011 15:54:32 -0500, James Vasile  
wrote:
> Sometimes I want to send a colleague a bunch of emails (for example, all
> the emails I've tagged todo or all the emails from an awesome
> contributor.  Although notmuch usually speaks the language of maildirs,
> I find mboxes most convenient for attaching to emails.  Their tools can
> usually handle it well.
> 
> I've put a bit of elisp and python up:
> https://github.com/jvasile/notmuch2mbox

Hi, James.  Are you aware of the --format=mbox output option for notmuch
show?  I think it already supports just this exact use case.  See
"notmuch help show" for more info.

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

Re: Make MBox

[Jameson Rollins]

On Tue, 01 Mar 2011 15:54:32 -0500, James Vasile ja...@hackervisions.org 
wrote:
 Sometimes I want to send a colleague a bunch of emails (for example, all
 the emails I've tagged todo or all the emails from an awesome
 contributor.  Although notmuch usually speaks the language of maildirs,
 I find mboxes most convenient for attaching to emails.  Their tools can
 usually handle it well.
 
 I've put a bit of elisp and python up:
 https://github.com/jvasile/notmuch2mbox

Hi, James.  Are you aware of the --format=mbox output option for notmuch
show?  I think it already supports just this exact use case.  See
notmuch help show for more info.

jamie.


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

Re: Strange match to my query

[Jameson Rollins]

On Tue, 1 Mar 2011 16:00:51 -0700, Mark Anderson markr.ander...@amd.com wrote:
 On Fri, 25 Feb 2011 15:29:05 -0600, Jameson Rollins 
 jroll...@finestructure.net wrote:
  So I am in fact still seeing this bug, although I am ostensibly using a
  version that includes the patch to fix it (db70f3f0).  Does this fix
  require rebuilding the database?
 
 Yes.

 The termlist is constructed when the message is added to the database,
 so the database must be reconstructed.
 
 Newer messages will index email addresses so that they can't be matched
 by overlapping term indexes.  However, the corpus of your database is
 not going to change without manual intervention.

Ok, that's what I thought.  Thanks for the feedback, Mark.
 
 A simple rebuild when you go to bed can look like:

I think you're missing an important step:

notmuch dump dump.txt
mv $(notmuch config get database.path){,.bak}
notmuch new
notmuch restore dump.txt

but I get the idea ;)

Thanks again.

jamie.


pgpMEtx1OyXaO.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

[Jameson Rollins]

On Mon, 28 Feb 2011 21:16:13 -0600, Rob Browning  
wrote:
> Are persistent tags required here?  The original question at least,
> seemed to just be asking for a visual indicator that a message has
> encrypted or signed bits.  So I wondered if that might be accomplished
> without actual tags.

Hey, Rob.  It probably could, but given that we already have
infrastructure for modifying the face of lines in the search output
based on tags, it therefore seems like the easiest way to achieve the
indicator that Ross was interested in would also be via a tag.  Any
other method would probably require extra hacking of the search
function, and hacking of the emacs interface to parse it and act on it.

To me personally the issue was more about wanting to be able to easily
find signed or encrypted messages.  The easiest way to do that would be
with a tag also, since that's kind of what they're for (again I can
imagine some other sort of internal flag in the database, but that seems
like it would be a lot more work).

Given that it should be fairly easy to tag these messages during notmuch
new, and that tags can be easily leveraged by existing functions, tags
seem to me to be the way to go.

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

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

[Jameson Rollins]

On Mon, 28 Feb 2011 15:08:39 -0500, Daniel Kahn Gillmor  wrote:
> The outstanding question in my mind is whether those tags could be
> mistaken by a na?ve user for meaning one of the other concepts.  Is
> there a way to name the tags to minimize that kind of confusion?

I think that would be difficult without using a long and cumbersome tag
name ("signed-but-not-verified"??).  But I think it might be a bit of a
moot point, since I kind of think that any user that actually
understands what a signature is, and what signature verification means,
is sophisticated enough to understand that the mere presence of a
signature does not mean it's been verified.  I could be wrong, though.

If folks have suggestions for disambiguating tag names that don't
themselves create further confusion on some other front, then I'm
inclined to just go with the simplest and most straightforward tag name.

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

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

[Jameson Rollins]

On Mon, 28 Feb 2011 13:59:54 -0500, Daniel Kahn Gillmor  wrote:
> But: what does the "signed" tag mean? i wouldn't want to necessarily
> conflate these four ideas:

These are good points, Daniel.  However, I had actually just been
thinking of something much simpler, along the lines of just tagging
"signed" any message with a "multipart/signed" part, and "encrypted" any
message with a "multipart/encrypted" part.

This simpler approach would certainly satisfy my needs, without having
to get into sorting out all the complicated details in the points you
brought up.

Does that sound like it would work for folks, or would they like to see
a more nuanced approach to handling tagging of signed/encrypted
messages?

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

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

[Jameson Rollins]

On Mon, 28 Feb 2011 08:52:45 -0500, Ross Glover  
wrote:
> I too am now running the crypto branch and find it quite amazing.  The
> one feature I would like added, though, is some face color or
> auto-tagging in the search buffer for mail with encrypted mime parts.
> It seems like this could be achieved with notmuch effort (by someone
> notme) by adding similar functionality to that of attachments in
> index.cc.

Yes, this is a good idea, Ross, and one that I've actually been wanting
to implement.  I was thinking of auto-tagging messages with signed parts
with something like "signed", and encrypted messages with "encrypted".
Do people like those tags, or would they prefer to see something
different?  Or more specific, like "pgp-signed"?

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

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

[Jameson Rollins]

On Mon, 28 Feb 2011 13:59:54 -0500, Daniel Kahn Gillmor 
d...@fifthhorseman.net wrote:
 But: what does the signed tag mean? i wouldn't want to necessarily
 conflate these four ideas:

These are good points, Daniel.  However, I had actually just been
thinking of something much simpler, along the lines of just tagging
signed any message with a multipart/signed part, and encrypted any
message with a multipart/encrypted part.

This simpler approach would certainly satisfy my needs, without having
to get into sorting out all the complicated details in the points you
brought up.

Does that sound like it would work for folks, or would they like to see
a more nuanced approach to handling tagging of signed/encrypted
messages?

jamie.


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

running the crypto branch [was: Re: Hiding HTML mime-parts and/or scrubbing (gmail's) HTML-based citation]

[Jameson Rollins]

On Sun, 27 Feb 2011 01:00:08 +0100, Xavier Maillard  
wrote:
> What is the easy way to switch to your codebase from notmuch mainline ?
> I mean, what exact commands do we need to type in order to use your
> branch code ? Knowing that would certainly help people in switching and
> testing your code.

Hey, Xavier.  Thanks for asking.  Here's what I would suggest:

1. Add my public repo as a remote in your notmuch git repository:

$ git remote add jrollins git://finestructure.net/notmuch

2. Update your remotes to pull in the remote branches

$ git remote update

At this point you should see my public branches as remote-tracking
branches in your repository, e.g.:

$ git branch -a
...
  remotes/jrollins/crypto
  remotes/jrollins/master
  remotes/jrollins/personal

3. Check out my crypto branch into a local branch:

$ git checkout --track jrollins/crypto

This will put you in a new local branch in your repository called
"crypto" that will be tracking my public crypto branch.

4. Compile notmuch in the crypto branch and install it, however you
usually do.  I do something like this:

./configure --prefix=~/opt/notmuch
make
make test
make install

I then run notmuch in emacs like this:

export LD_LIBRARY_PATH=~/opt/notmuch/lib:$LD_LIBRARY_PATH
emacs -L ~/opt/notmuch/share/emacs/site-lisp -f notmuch

I hope that helps.  Please let me know if you have any other questions.
And of course we'd love to hear any and all feedback on the new
cryptographic features!

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

running the crypto branch [was: Re: Hiding HTML mime-parts and/or scrubbing (gmail's) HTML-based citation]

[Jameson Rollins]

On Sun, 27 Feb 2011 01:00:08 +0100, Xavier Maillard xav...@maillard.im wrote:
 What is the easy way to switch to your codebase from notmuch mainline ?
 I mean, what exact commands do we need to type in order to use your
 branch code ? Knowing that would certainly help people in switching and
 testing your code.

Hey, Xavier.  Thanks for asking.  Here's what I would suggest:

1. Add my public repo as a remote in your notmuch git repository:

$ git remote add jrollins git://finestructure.net/notmuch

2. Update your remotes to pull in the remote branches

$ git remote update

At this point you should see my public branches as remote-tracking
branches in your repository, e.g.:

$ git branch -a
...
  remotes/jrollins/crypto
  remotes/jrollins/master
  remotes/jrollins/personal

3. Check out my crypto branch into a local branch:

$ git checkout --track jrollins/crypto

This will put you in a new local branch in your repository called
crypto that will be tracking my public crypto branch.

4. Compile notmuch in the crypto branch and install it, however you
usually do.  I do something like this:

./configure --prefix=~/opt/notmuch
make
make test
make install

I then run notmuch in emacs like this:

export LD_LIBRARY_PATH=~/opt/notmuch/lib:$LD_LIBRARY_PATH
emacs -L ~/opt/notmuch/share/emacs/site-lisp -f notmuch

I hope that helps.  Please let me know if you have any other questions.
And of course we'd love to hear any and all feedback on the new
cryptographic features!

jamie.


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

Strange match to my query

[Jameson Rollins]

On Fri, 25 Feb 2011 13:57:23 -0700, Mark Anderson  
wrote:
> It shouldn't match anything, that's the value of finding this bug.
> 
> What happened is the term counter was reset for each email address, so
> the term list for emails in "to:" looks something like this:
> 
> 0 c  K
> 1 hello  R
> 2 comgoodbye
> 3com
> 
> So it matched a hello at 1 and a goodbye at 2.

I see now.  I was confused about which problem you were reporting.

So I am in fact still seeing this bug, although I am ostensibly using a
version that includes the patch to fix it (db70f3f0).  Does this fix
require rebuilding the database?

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

Strange match to my query

[Jameson Rollins]

On Tue, 25 Jan 2011 16:29:22 -0700, Mark Anderson  
wrote:
> Apparently matching on email addresses doesn't work the way I hoped.
> 
> While debugging why my to:x at y.com search was matching far too many
> entries, I whittled it down to this:
> 
> WORD1=hello
> WORD2=goodbye
> MSGID=junk$(date +%s)
> TESTDIR=$(notmuch config get database.path)/.tmp/new
> TESTMAIL=$TESTDIR/$MSGID:2,
> 
> mkdir -p $TESTDIR
> 
> echo Testcase for $WORD1@$WORD2, msgid: $MSGID at junk.com
> 
> echo "From: nobody at nobody.com
> To: c@${WORD1}.com, K-R@${WORD2}.com
> Date: Mon, 24 Jan 2011 23:41:34 -0600
> Subject: Error
> Message-ID: <$MSGID at junk.com>
> 
> Not empty body.=
> 
> " > $TESTMAIL
> 
> notmuch new
> notmuch search --output=files to:$WORD1@$WORD2
> notmuch search --output=files to:\"$WORD1@$WORD2\"
> 
> Why does that match, but this doesn't?
> 
> notmuch search --output=files to:\'$WORD1@$WORD2\'

Hey, guys.  Reopening an old thread here, found while trying to track
down a similar problem.

I'm confused why any of these searches should return anything at all.
"$WORD1@$WORD2" doesn't actually match either of the addresses in the
test message, especially when quoted.  The expanded addresses should be:

  c at hello.com
  K-R at goodbye.com

Why should

  hello at goodbye

match anything?  And in fact it doesn't for me if I recreate the same
setup.  Am I missing something?

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

Hiding HTML mime-parts and/or scrubbing (gmail's) HTML-based citation

[Jameson Rollins]

On Wed, 23 Feb 2011 15:10:22 +0100, Albin Stjerna  wrote:
> On Tue, 22 Feb 2011 14:59:03 -0500, Daniel Kahn Gillmor  fifthhorseman.net> wrote:
> 
> > I'm running the crypto branch (from jrollins, available at
> > git://finestructure.net/notmuch ), which incorporates dme's multipart
> > MIME overhaul.
> 
> Ah. I've now built and installed that one, and it works as you described
> it. Thanks!
> 
> Is there a plan for the inclusion of this branch in mainline notmuch?

Carl has expressed interest in the crypto work, but he hasn't commented
on the work in that branch directly yet.  I will certainly continue to
push for it's inclusion.

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

ordering threads by the latest message in a thread ?

[Jameson Rollins]

On Wed, 9 Feb 2011 10:28:17 +0100, Sebastien Binet  wrote:
> right now, it seems like the messages are displayed and ordered in my
> inbox according to the date of the *first* message in a thread.
> 
> that doesn't sound right to me as one can easily miss new replies to
> that thread (at least I did.)
> 
> is there a way to modify this in the notmuch emacs interface so that
> threads are ordered according to the *latest* message in a thread
> instead ?

Hi, Sebastien.  You can access the notmuch emacs config parameters by
doing:

M-x customize-group notmuch

There is a variable there called "Notmuch Search Oldest First" that does
what you're looking for.

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

new "crypto" branch providing full PGP/MIME support

[Jameson Rollins]

Hey, folks.  I've pushed some improvements to the "crypto" branch that:

* add support for replying to encrypted messages
* don't show sigstatus button for unsigned encrypted messages

As always, please let me know encounter any problems.

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

new "crypto" branch providing full PGP/MIME support

[Jameson Rollins]

On Fri, 04 Feb 2011 13:12:27 -0400, David Bremner  wrote:
> I reported some pretty weird experiences yesterday on IRC with replies
> not working. It turns out they were caused by having old versions of
> xapian installed in /usr/local (which I think might have caused some
> mixup with headers and libraries being different versions).
> 
> The decryption is working ok for me now (aside from the issue I
> mentioned already with unknown encrypted+signed).
...
> tl;dr: yesterdays weirdness was not the fault of J. Rollins.

phew!  Although there remains the issue of replying to encrypted
messages, since notmuch-reply was not modified to decrypt messages
before replying.  I'm working on that now.

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

new "crypto" branch providing full PGP/MIME support

[Jameson Rollins]

On Fri, 04 Feb 2011 12:09:48 +, Darren McGuicken  wrote:
> On Thu, 03 Feb 2011 13:02:41 -0800, Jameson Rollins  finestructure.net> 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!

Thanks for the feedback!

> 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.

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.

jamie.
-- 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/20110204/a14fe560/attachment.pgp>

always encrypting messages to self [was: Re: new "crypto" branch providing full PGP/MIME support]

[Jameson Rollins]

On Fri, 04 Feb 2011 14:04:23 +0100, Sebastian Spaeth  
wrote:
> I just love seeing all those yellow signatures. It reminds me to meet
> you all in real life to verify your keys :-).
> 
> Thanks for implementing this, the whole lot of you. It works really
> well.

Yes!  I'm really glad you're finding it useful.  Hopefully you're seeing
some green fully-valid-userid sigs in there as well...

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

new "crypto" branch providing full PGP/MIME support

[Jameson Rollins]

On Fri, 04 Feb 2011 08:24:38 -0400, David Bremner  wrote:
> On Wed, 02 Feb 2011 17:18:45 -0800, Jameson Rollins  finestructure.net> wrote:
> > Hi, all.  I have pushed a new branch called "crypto" to my notmuch
> > repository [0].  This branch provides full support for PGP/MIME signed
> > and encrypted messages, including emacs UI support.  It has been applied
> > on top of cworth's current master (21e97c50).  It includes the
> > following:
> > 
> 
> For a signed and encrypted message, if the signing key can't be found,
> one just gets:
> 
>  [ multipart/encrypted: decryption error ]
> 
> which is a bit mystifying.  At least gpg on the command line will
> decrypt the message and print a warning about the signature.

So I need to look at this closer, but I think this is a GMime problem.
That error message is generated when the GMime decryption code returns
NULL for the decrypted part.  I'll try to make a test case for this, and
file a bug with GMime upstream.

jamie.
-- 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/20110204/ce9426d4/attachment.pgp>

Re: new crypto branch providing full PGP/MIME support

[Jameson Rollins]

On Fri, 04 Feb 2011 08:24:38 -0400, David Bremner brem...@unb.ca wrote:
 On Wed, 02 Feb 2011 17:18:45 -0800, Jameson Rollins 
 jroll...@finestructure.net wrote:
  Hi, all.  I have pushed a new branch called crypto to my notmuch
  repository [0].  This branch provides full support for PGP/MIME signed
  and encrypted messages, including emacs UI support.  It has been applied
  on top of cworth's current master (21e97c50).  It includes the
  following:
  
 
 For a signed and encrypted message, if the signing key can't be found,
 one just gets:
 
  [ multipart/encrypted: decryption error ]
 
 which is a bit mystifying.  At least gpg on the command line will
 decrypt the message and print a warning about the signature.

So I need to look at this closer, but I think this is a GMime problem.
That error message is generated when the GMime decryption code returns
NULL for the decrypted part.  I'll try to make a test case for this, and
file a bug with GMime upstream.

jamie.


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

Re: always encrypting messages to self [was: Re: new crypto branch providing full PGP/MIME support]

[Jameson Rollins]

On Fri, 04 Feb 2011 14:04:23 +0100, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 I just love seeing all those yellow signatures. It reminds me to meet
 you all in real life to verify your keys :-).
 
 Thanks for implementing this, the whole lot of you. It works really
 well.

Yes!  I'm really glad you're finding it useful.  Hopefully you're seeing
some green fully-valid-userid sigs in there as well...

jamie.


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

Re: new crypto branch providing full PGP/MIME support

[Jameson Rollins]

On Fri, 04 Feb 2011 12:09:48 +, Darren McGuicken 
mailing-notm...@fernseed.info wrote:
 On Thu, 03 Feb 2011 13:02:41 -0800, Jameson Rollins 
 jroll...@finestructure.net 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!

Thanks for the feedback!

 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.

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.

jamie.


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

Re: new crypto branch providing full PGP/MIME support

[Jameson Rollins]

On Fri, 04 Feb 2011 13:12:27 -0400, David Bremner brem...@unb.ca wrote:
 I reported some pretty weird experiences yesterday on IRC with replies
 not working. It turns out they were caused by having old versions of
 xapian installed in /usr/local (which I think might have caused some
 mixup with headers and libraries being different versions).
 
 The decryption is working ok for me now (aside from the issue I
 mentioned already with unknown encrypted+signed).
...
 tl;dr: yesterdays weirdness was not the fault of J. Rollins.

phew!  Although there remains the issue of replying to encrypted
messages, since notmuch-reply was not modified to decrypt messages
before replying.  I'm working on that now.

jamie.


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

new "crypto" branch providing full PGP/MIME support

[Jameson Rollins]

On Thu, 03 Feb 2011 20:42:38 +, Darren McGuicken  wrote:
> On Wed, 02 Feb 2011 17:18:45 -0800, Jameson Rollins  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!

Thanks!  I hope people find it useful.

> 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?

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.

jamie.

-- 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/20110203/9b51ebd4/attachment.pgp>

new "crypto" branch providing full PGP/MIME support

[Jameson Rollins]

On Thu, 03 Feb 2011 14:52:01 -0500, Daniel Kahn Gillmor  wrote:
> On 02/03/2011 11:25 AM, micah anderson wrote:
> > 1. I personally think notmuch-show-process-pgpmime should default to
> > true
> 
> note that with it set to false, you can still M-RET (instead of RET) on
> an item in the summary window to have it set for that particular view.

This is also useful if you set notmuch-show-process-pgpmime and ever
come across a message that is causing crypto problems.  M-RET will
return you to the normal view.

> > 3. i'm not sure expired/revoked keys are handled properly - tested on a
> > message that was encrypted by a key that was revoked and got "End of
> > file during parsing"
> 
> when you say "encrypted by" do you mean "encrypted to"?  do you have
> access to the corresponding secret key?

I also seem to be noticing issues with revoked keys.  I'm looking in to
the issue.  If anyone else notices something similar, please do relay
your experience.

> > 4. messages that I sent encrypted to someone are not also encrypted to
> > myself, which means that a thread which contains my replies isn't able
> > to decrypt my messages in that thread and results in a purple
> > 'decryption error'. Perhaps this is an emacs UI tweak that needs to be
> > made to get messages also encrypted to my own key?
> 
> this is an issue for the emacs message modes (or maybe for your gpg
> configuration), not for notmuch.
> 
> You either want to fix this in your emacs config by putting your
> fingerprint into mml2015-signers and setting mml2015-encrypt-to-self
> 
> Or you want to set gpg's default-recipient-self option  (and
> default-recipient option if you hold more than one secret key and want
> to be sure it chooses the right one)

Actually, I think the gpg option we're looking for here is
"encrypt-to".  "default-recipient-self" sets the recipient only if none
other is specified.  I just set "encrypt-to " in my gpg.conf
and it seems to do as expected (all encrypted messages are also
encrypted to myself).

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

new crypto branch providing full PGP/MIME support

[Jameson Rollins]

Hi, all.  I have pushed a new branch called crypto to my notmuch
repository [0].  This branch provides full support for PGP/MIME signed
and encrypted messages, including emacs UI support.  It has been applied
on top of cworth's current master (21e97c50).  It includes the
following:

* David Edmondson's improved multipart handling patch series (cherry-picked)
* Daniel Gillmor's PGP/MIME signature verification patch series (cherry-picked)
* my PGP/MIME decryption+verification patch series
* a test suite for signature verification and decryption
* emacs support for the above

I have signed-off on all cherry-picked commits, as I have reviewed and
tested them extensively (I have been using them in my daily notmuch use
for many months now).  The multipart and sig-verification patches were
cherry-picked to get around a couple of accidental spurious commits in
their originating branches that would have needed to be reverted.

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.

jamie.

[0] git://finestructure.net/notmuch


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

Re: new crypto branch providing full PGP/MIME support

[Jameson Rollins]

On Thu, 03 Feb 2011 20:42:38 +, Darren McGuicken 
mailing-notm...@fernseed.info wrote:
 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!

Thanks!  I hope people find it useful.

 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?

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.

jamie.



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

new "crypto" branch providing full PGP/MIME support

[Jameson Rollins]

Hi, all.  I have pushed a new branch called "crypto" to my notmuch
repository [0].  This branch provides full support for PGP/MIME signed
and encrypted messages, including emacs UI support.  It has been applied
on top of cworth's current master (21e97c50).  It includes the
following:

* David Edmondson's improved multipart handling patch series (cherry-picked)
* Daniel Gillmor's PGP/MIME signature verification patch series (cherry-picked)
* my PGP/MIME decryption+verification patch series
* a test suite for signature verification and decryption
* emacs support for the above

I have signed-off on all cherry-picked commits, as I have reviewed and
tested them extensively (I have been using them in my daily notmuch use
for many months now).  The multipart and sig-verification patches were
cherry-picked to get around a couple of accidental spurious commits in
their originating branches that would have needed to be reverted.

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.

jamie.

[0] git://finestructure.net/notmuch
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH] emacs: send notmuch-query stderr to /dev/null

[Jameson Rollins]

On Thu, 27 Jan 2011 14:49:43 +1000, Carl Worth  wrote:
> On Wed, 26 Jan 2011 12:57:50 -0800, Jameson Rollins  finestructure.net> wrote:
> > The call-process to notmuch in notmuch-query.el was previously sending
> > stderr into the output buffer.  This means that if there is any stderr
> > the JSON parsing breaks.  Unfortunately call-process does not support
> > sending stderr to a separate buffer or to the minibuffer [0], but it
> > does support sending it to /dev/null.  So we do that here instead.
> > 
> > [0] a bug was filed against emacs (#7842)
> 
> Thanks! I had wondered what those json errors were about. I've committed
> this.
> 
> I am a bit concerned about throwing the error output away, of course,
> (so we'll wait for that fix to emacs---thanks for submitting a bug
> report). Do you have a sense of what kinds of output we are getting on
> stderr?

So the only stderr output I've ever seen seen is in the
signature-verification branch (which I now run).  Emails with S/MIME
signatures are currently not handled (because of GMIME limitations, I
think) and notmuch throws the following error when trying to process
them:

servo:~ 0$ notmuch show --format=json --verify id:"4D25D062.1000103 at 
sixdemonbag.org" >/dev/null
Failed to verify signed part: no error explanation given
servo:~ 0$ 

Obviously the emacs call-process function should be capturing and
displaying those error messages.  Hopefully we can eventually get that
fixed.  In the mean time it's probably better to throw out the messages
rather than have them break the JSON output.

jamie.
-- 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/20110127/eb9e93ae/attachment.pgp>

notmuch's idea of concurrency / failing an invocation

[Jameson Rollins]

On Thu, 27 Jan 2011 13:40:25 -0500, micah anderson  wrote:
> Due to my harddisk in my laptop being slow (5400RPM), my notmuch
> database growing, and perhaps some fragmentation somewhere, this has
> become *incredibly* annoying for me. I am checking email every 30
> minutes, and I'm nicing and ionicing the processes so I can use my
> machine, but while those processes are running, I'm effectively locked
> out of a good portion of my email. 

I also have a very slow disk, but this is very rarely a problem for me.
I retrieve mail every 10 minutes, and the corresponding notmuch new
usually takes a minute or so.  I really haven't found it to be much of a
bother to just wait it out.

One of the suggested ways to develop around this problem would be a
notmuch daemon that would queue database modification requests.  I don't
think anyone has been working on this yet, but if this is a big problem
for you guys, you might start looking into putting one together.

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

Re: notmuch's idea of concurrency / failing an invocation

[Jameson Rollins]

On Thu, 27 Jan 2011 13:40:25 -0500, micah anderson mi...@riseup.net wrote:
 Due to my harddisk in my laptop being slow (5400RPM), my notmuch
 database growing, and perhaps some fragmentation somewhere, this has
 become *incredibly* annoying for me. I am checking email every 30
 minutes, and I'm nicing and ionicing the processes so I can use my
 machine, but while those processes are running, I'm effectively locked
 out of a good portion of my email. 

I also have a very slow disk, but this is very rarely a problem for me.
I retrieve mail every 10 minutes, and the corresponding notmuch new
usually takes a minute or so.  I really haven't found it to be much of a
bother to just wait it out.

One of the suggested ways to develop around this problem would be a
notmuch daemon that would queue database modification requests.  I don't
think anyone has been working on this yet, but if this is a big problem
for you guys, you might start looking into putting one together.

jamie.


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

PGP/MIME signature verification

[Jameson Rollins]

On Mon, 20 Dec 2010 13:22:07 -0500, Jameson Rollins  wrote:
> On Sat, 27 Nov 2010 14:35:03 -0500, Daniel Kahn Gillmor  fifthhorseman.net> wrote:
> > the signature-verification branch on my git repo [0] contains functional
> > PGP/MIME signature verification if you supply the --verify argument to
> > 
> >  notmuch show --format=json
> > 
> > It relies on gpg being in the path, and on the user having the signer's
> > key in their gnupg keyring.
> 
> I was able to merge dkg's signature-verification branch on top of
> cworth's current master head (b3caef1f) with only a tiny
> easily-resolvable conflict.  It seems to work exactly as advertised, and
> I wholeheartedly approve and endorse this patch set for inclusion
> upstream:
> 
> Approved-and-Tested-By: Jameson Rollins 

Hi, all.  I have rebased the "signature-verification" branch against the
current (as of now) head of cworth's master (74cb76a6) and pushed it to
my repo:

git://finestructure.net/notmuch

Carl: please let me know if this is suitable for pulling into your
master branch, and definitely let me know if there's anything else I can
do to facilitate getting these patches included.

jamie.
-- 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/20110126/ec2d6dcf/attachment.pgp>

[PATCH] emacs: send notmuch-query stderr to /dev/null

[Jameson Rollins]

The call-process to notmuch in notmuch-query.el was previously sending
stderr into the output buffer.  This means that if there is any stderr
the JSON parsing breaks.  Unfortunately call-process does not support
sending stderr to a separate buffer or to the minibuffer [0], but it
does support sending it to /dev/null.  So we do that here instead.

[0] a bug was filed against emacs (#7842)
---
 emacs/notmuch-query.el |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch-query.el b/emacs/notmuch-query.el
index 26f9544..921f624 100644
--- a/emacs/notmuch-query.el
+++ b/emacs/notmuch-query.el
@@ -35,7 +35,7 @@ is a possibly empty forest of replies.
 (json-false 'nil))
 (with-temp-buffer
   (progn
-   (apply 'call-process (append (list notmuch-command nil t nil) args))
+   (apply 'call-process (append (list notmuch-command nil (list t nil) 
nil) args))
(goto-char (point-min))
(json-read)

-- 
1.7.2.3

[PATCH] emacs: send notmuch-query stderr to /dev/null

[Jameson Rollins]

The call-process to notmuch in notmuch-query.el was previously sending
stderr into the output buffer.  This means that if there is any stderr
the JSON parsing breaks.  Unfortunately call-process does not support
sending stderr to a separate buffer or to the minibuffer [0], but it
does support sending it to /dev/null.  So we do that here instead.

[0] a bug was filed against emacs (#7842)
---
 emacs/notmuch-query.el |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch-query.el b/emacs/notmuch-query.el
index 26f9544..921f624 100644
--- a/emacs/notmuch-query.el
+++ b/emacs/notmuch-query.el
@@ -35,7 +35,7 @@ is a possibly empty forest of replies.
 (json-false 'nil))
 (with-temp-buffer
   (progn
-   (apply 'call-process (append (list notmuch-command nil t nil) args))
+   (apply 'call-process (append (list notmuch-command nil (list t nil) 
nil) args))
(goto-char (point-min))
(json-read)
 
-- 
1.7.2.3

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

Re: PGP/MIME signature verification

[Jameson Rollins]

On Mon, 20 Dec 2010 13:22:07 -0500, Jameson Rollins 
jroll...@finestructure.net wrote:
 On Sat, 27 Nov 2010 14:35:03 -0500, Daniel Kahn Gillmor 
 d...@fifthhorseman.net wrote:
  the signature-verification branch on my git repo [0] contains functional
  PGP/MIME signature verification if you supply the --verify argument to
  
   notmuch show --format=json
  
  It relies on gpg being in the path, and on the user having the signer's
  key in their gnupg keyring.
 
 I was able to merge dkg's signature-verification branch on top of
 cworth's current master head (b3caef1f) with only a tiny
 easily-resolvable conflict.  It seems to work exactly as advertised, and
 I wholeheartedly approve and endorse this patch set for inclusion
 upstream:
 
 Approved-and-Tested-By: Jameson Rollins jroll...@finestructure.net

Hi, all.  I have rebased the signature-verification branch against the
current (as of now) head of cworth's master (74cb76a6) and pushed it to
my repo:

git://finestructure.net/notmuch

Carl: please let me know if this is suitable for pulling into your
master branch, and definitely let me know if there's anything else I can
do to facilitate getting these patches included.

jamie.


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

[PATCH 1/4] Import date/time parser from GNU coreutils

[Jameson Rollins]

On Sun, 23 Jan 2011 12:47:24 +0100, Michal Sojka  wrote:
> This function have quite a lot dependencies. We may reduce them later it
> it is a problem.
> ---
>  lib/c-ctype.c  |  398 +++
>  lib/c-ctype.h  |  297 +
>  lib/getdate.c  | 3497 
> 
>  lib/getdate.h  |   22 +
>  lib/getdate.y  | 1572 +
>  lib/gettime.c  |   48 +
>  lib/intprops.h |   83 ++
>  lib/timespec.h |   39 +
>  lib/verify.h   |  140 +++
>  9 files changed, 6096 insertions(+), 0 deletions(-)
>  create mode 100644 lib/c-ctype.c
>  create mode 100644 lib/c-ctype.h
>  create mode 100644 lib/getdate.c
>  create mode 100644 lib/getdate.h
>  create mode 100644 lib/getdate.y
>  create mode 100644 lib/gettime.c
>  create mode 100644 lib/gettime.h
>  create mode 100644 lib/intprops.h
>  create mode 100644 lib/timespec.h
>  create mode 100644 lib/verify.h

Hi, Michal.  I don't fully understand what's going on here, but it seems
like you're embedding code copies from somewhere else.  If that's the
case, is there a reason that we would need to do that, rather than just
linking against an external library?

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

Re: [PATCH 1/4] Import date/time parser from GNU coreutils

[Jameson Rollins]

On Sun, 23 Jan 2011 12:47:24 +0100, Michal Sojka sojk...@fel.cvut.cz wrote:
 This function have quite a lot dependencies. We may reduce them later it
 it is a problem.
 ---
  lib/c-ctype.c  |  398 +++
  lib/c-ctype.h  |  297 +
  lib/getdate.c  | 3497 
 
  lib/getdate.h  |   22 +
  lib/getdate.y  | 1572 +
  lib/gettime.c  |   48 +
  lib/intprops.h |   83 ++
  lib/timespec.h |   39 +
  lib/verify.h   |  140 +++
  9 files changed, 6096 insertions(+), 0 deletions(-)
  create mode 100644 lib/c-ctype.c
  create mode 100644 lib/c-ctype.h
  create mode 100644 lib/getdate.c
  create mode 100644 lib/getdate.h
  create mode 100644 lib/getdate.y
  create mode 100644 lib/gettime.c
  create mode 100644 lib/gettime.h
  create mode 100644 lib/intprops.h
  create mode 100644 lib/timespec.h
  create mode 100644 lib/verify.h

Hi, Michal.  I don't fully understand what's going on here, but it seems
like you're embedding code copies from somewhere else.  If that's the
case, is there a reason that we would need to do that, rather than just
linking against an external library?

jamie.


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

PGP/MIME signature verification

[Jameson Rollins]

On Sat, 27 Nov 2010 14:35:03 -0500, Daniel Kahn Gillmor  wrote:
> the signature-verification branch on my git repo [0] contains functional
> PGP/MIME signature verification if you supply the --verify argument to
> 
>  notmuch show --format=json
> 
> It relies on gpg being in the path, and on the user having the signer's
> key in their gnupg keyring.

I was able to merge dkg's signature-verification branch on top of
cworth's current master head (b3caef1f) with only a tiny
easily-resolvable conflict.  It seems to work exactly as advertised, and
I wholeheartedly approve and endorse this patch set for inclusion
upstream:

Approved-and-Tested-By: Jameson Rollins 

I have pushed a merged "signature-verification" branch to my repo, along
with a single commit to fix an errant newline in the json --verify
output:

git://finestructure.net/notmuch

Carl: can you give an indication of whether or not you intend to
ultimately accept this patch set?  If so, I would like to start work on
representing signature verification information in the emacs UI.  I want
to make sure that we're good with this effort first, though.

We should probably also start a conversation about how best to represent
the signature verification info.  I'll bring that up in a separate
thread, though.

dkg: again, great work on this!  Thanks!

Next up: decrypting!

jamie.
-- 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/20101220/749f9af2/attachment.pgp>

Re: PGP/MIME signature verification

[Jameson Rollins]

On Sat, 27 Nov 2010 14:35:03 -0500, Daniel Kahn Gillmor 
d...@fifthhorseman.net wrote:
 the signature-verification branch on my git repo [0] contains functional
 PGP/MIME signature verification if you supply the --verify argument to
 
  notmuch show --format=json
 
 It relies on gpg being in the path, and on the user having the signer's
 key in their gnupg keyring.

I was able to merge dkg's signature-verification branch on top of
cworth's current master head (b3caef1f) with only a tiny
easily-resolvable conflict.  It seems to work exactly as advertised, and
I wholeheartedly approve and endorse this patch set for inclusion
upstream:

Approved-and-Tested-By: Jameson Rollins jroll...@finestructure.net

I have pushed a merged signature-verification branch to my repo, along
with a single commit to fix an errant newline in the json --verify
output:

git://finestructure.net/notmuch

Carl: can you give an indication of whether or not you intend to
ultimately accept this patch set?  If so, I would like to start work on
representing signature verification information in the emacs UI.  I want
to make sure that we're good with this effort first, though.

We should probably also start a conversation about how best to represent
the signature verification info.  I'll bring that up in a separate
thread, though.

dkg: again, great work on this!  Thanks!

Next up: decrypting!

jamie.


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

[PATCH 2/2] bind notmuch-search-date-restrict to 'S'

[Jameson Rollins]

---
 emacs/notmuch-show.el |1 +
 emacs/notmuch.el  |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 3a60d43..e1ace7c 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -579,6 +579,7 @@ function is used. "
(define-key map (kbd "") 'notmuch-show-previous-button)
(define-key map (kbd "TAB") 'notmuch-show-next-button)
(define-key map "s" 'notmuch-search)
+   (define-key map "S" 'notmuch-search-date-restrict)
(define-key map "m" 'notmuch-mua-mail)
(define-key map "f" 'notmuch-show-forward-message)
(define-key map "r" 'notmuch-show-reply)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 763d517..af5e310 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -206,6 +206,7 @@ For a mouse binding, return nil."
 (define-key map "r" 'notmuch-search-reply-to-thread)
 (define-key map "m" 'notmuch-mua-mail)
 (define-key map "s" 'notmuch-search)
+(define-key map "S" 'notmuch-search-date-restrict)
 (define-key map "o" 'notmuch-search-toggle-order)
 (define-key map "c" 'notmuch-search-stash-map)
 (define-key map "=" 'notmuch-search-refresh-view)
-- 
1.7.2.3

[PATCH 1/2] emacs function to perform a search with a look back time restriction

[Jameson Rollins]

This function allows for restricting the date range of a search, back
from the current time.  The look-back time range is given at a second
prompt.  An example time range is '4d' to indicate four days or '12y'
to indicate twelve years.

On slow machines this can speed up the search considerably.  I believe
this handles the most common usage where one wishes to perform a
search for a message that is known to have been received recently.

One might imagine extending this function to be able to handle date
ranges, such as "11/2004-2/2005", or it becoming obsolete if more
flexible date specs are folded into notmuch search directly.
---
 emacs/notmuch.el |   62 ++
 1 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 3d82f0d..763d517 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -948,6 +948,68 @@ current search results AND that are tagged with the given 
tag."
(list (notmuch-select-tag-with-completion "Filter by tag: ")))
   (notmuch-search (concat notmuch-search-query-string " and tag:" tag) 
notmuch-search-oldest-first))

+(defun notmuch-search-convert-time-spec (spec)
+  "Internal function to convert an abbreviated time spec into seconds."
+  (if (string= spec "")
+  0
+(let ((factor (replace-regexp-in-string "[Mhdwmy]$" "" spec))
+ (unit (replace-regexp-in-string "^[0123456789]*" "" spec))
+ seconds)
+  (if (string= factor "")
+ (setq factor 1)
+   (setq factor (string-to-number factor)))
+  (if (string= unit "")
+ (setq seconds 1)
+   (cond ((string= unit "M")
+  (setq seconds 60))
+ ((string= unit "h")
+  (setq seconds 3600))
+ ((string= unit "d")
+  (setq seconds 86400))
+ ((string= unit "w")
+  (setq seconds 604800))
+ ((string= unit "m")
+  (setq seconds 2678400))
+ ((string= unit "y")
+  (setq seconds 31536000))
+ (t
+  (setq seconds nil
+  (if (null seconds)
+ nil
+   (* factor seconds)
+
+(defun notmuch-search-date-restrict (query time-spec)
+  "Run \"notmuch search\" but with a look-back time restriction.
+
+This first argument is the query string.
+The second argument is a look-back time spec of the form 'XY',
+where X is an integer and Y is one of:
+  'M'  minute
+  'h'  hour
+  'd'  day
+  'w'  week
+  'm'  month
+  'y'  year
+For instance, a time spec of '3w' would return only search
+results from within the last three weeks.
+A time spec of nil returns the full search results.
+
+For more information see the \"notmuch-search\"."
+  (interactive "sNotmuch search: \nslook back?: ")
+  (let ((look-back (notmuch-search-convert-time-spec time-spec)))
+(cond ((null look-back)
+  (message "unknown time spec"))
+ ((= look-back 0)
+  (notmuch-search query))
+ (t
+  (let* ((now (current-time))
+ (start (time-subtract now (seconds-to-time look-back
+(notmuch-search (concat
+ query " "
+ (format-time-string "%s" start)
+ ".."
+ (format-time-string "%s" now
+
 ;;;###autoload
 (defun notmuch ()
   "Run notmuch and display saved searches, known tags, etc."
-- 
1.7.2.3

new emacs function for date-restricted searches

[Jameson Rollins]

The following patch introduces a new function for restricting search
results to messages within a certain look-back time.  For instance, if
the time specification '3w' is given then the search will be
restricted to messages received within the last three weeks.

The second patch binds this function to the 'S' key.

I have a feeling that Carl won't be into this patch, but I'm throwing
it out there anyway, just in case.  On my slow machine, use of this
function speeds up searches considerably, especially since most of the
time I'm just searching for recent messages anyway.

[PATCH 2/2] bind notmuch-search-date-restrict to 'S'

[Jameson Rollins]

---
 emacs/notmuch-show.el |1 +
 emacs/notmuch.el  |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 3a60d43..e1ace7c 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -579,6 +579,7 @@ function is used. 
(define-key map (kbd backtab) 'notmuch-show-previous-button)
(define-key map (kbd TAB) 'notmuch-show-next-button)
(define-key map s 'notmuch-search)
+   (define-key map S 'notmuch-search-date-restrict)
(define-key map m 'notmuch-mua-mail)
(define-key map f 'notmuch-show-forward-message)
(define-key map r 'notmuch-show-reply)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 763d517..af5e310 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -206,6 +206,7 @@ For a mouse binding, return nil.
 (define-key map r 'notmuch-search-reply-to-thread)
 (define-key map m 'notmuch-mua-mail)
 (define-key map s 'notmuch-search)
+(define-key map S 'notmuch-search-date-restrict)
 (define-key map o 'notmuch-search-toggle-order)
 (define-key map c 'notmuch-search-stash-map)
 (define-key map = 'notmuch-search-refresh-view)
-- 
1.7.2.3

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

[PATCH 0/3] composing patches

[Jameson Rollins]

On Fri, 10 Dec 2010 17:35:17 +0200, Felipe Contreras  wrote:
> Why it's not? The emacs UI is not really doing anything on top of
> 'notmuch reply'. And if it is, it can very well override that value.
> Besides, what about other users (vim)? Why not make the output of
> 'notmuch reply' ready to be dumped to sendmail?

I think this is a reasonable point.  But is there a reason that vim
can't fill in the Message-ID and User-Agent fields?  Presumably it does
when composing new messages, right?

That said, if the pre-filling in those fields will help other user
agents, then I don't see the binary shouldn't do that.  Like you said,
other user agents (like emacs) can change them if they see fit.

> It seems right now there's a lot of reliance on emacs UI, and gnus.

I don't think there's any reliance on gnus.  I certainly don't use it.

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

Notmuch with multiple imap accounts?

[Jameson Rollins]

On Tue, 07 Dec 2010 08:43:58 +1100, Bart Bunting  wrote:
> I have recently had to split my mail in to two imap accounts.
> 
> Up until now I have been using notmuch with no issues with one account
> and offlineimap.
> 
> All my email is under ~/MAIL.
> 
> I can configure offlineimap with two accounts each in a different
> directory.  However I am not sure how I can configure notmuch to work in
> this way?  If anyone has any tips or pointers that would be greatly
> appreciated.  I presume what I need to do is to move my two maildirs
> under a common directory and tell notmuch to index that?  Or is there a
> way to have notmuch look at multiple maildirs?

Hi, Burt.  Notmuch indexes everything recursively under the top-level
directory specified in the notmuch database.path config variable.  If
~/MAIL is your primary directory, then as long as offlineimap delivers
mail from all imap accounts to directories under that path, then there
should be no problem.

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

Re: Notmuch with multiple imap accounts?

[Jameson Rollins]

On Tue, 07 Dec 2010 08:43:58 +1100, Bart Bunting b...@ursys.com.au wrote:
 I have recently had to split my mail in to two imap accounts.
 
 Up until now I have been using notmuch with no issues with one account
 and offlineimap.
 
 All my email is under ~/MAIL.
 
 I can configure offlineimap with two accounts each in a different
 directory.  However I am not sure how I can configure notmuch to work in
 this way?  If anyone has any tips or pointers that would be greatly
 appreciated.  I presume what I need to do is to move my two maildirs
 under a common directory and tell notmuch to index that?  Or is there a
 way to have notmuch look at multiple maildirs?

Hi, Burt.  Notmuch indexes everything recursively under the top-level
directory specified in the notmuch database.path config variable.  If
~/MAIL is your primary directory, then as long as offlineimap delivers
mail from all imap accounts to directories under that path, then there
should be no problem.

jamie.


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

PGP/MIME signature verification

[Jameson Rollins]

On Sat, 27 Nov 2010 14:35:03 -0500, Daniel Kahn Gillmor  wrote:
> the signature-verification branch on my git repo [0] contains functional
> PGP/MIME signature verification if you supply the --verify argument to
> 
>  notmuch show --format=json

Daniel, this is really incredible.  I can't tell you how much I
appreciate all of your effort on this front.  This is really a very
fundamental improvement to this tool.  I can't wait to test it out!

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

Re: PGP/MIME signature verification

[Jameson Rollins]

On Sat, 27 Nov 2010 14:35:03 -0500, Daniel Kahn Gillmor 
d...@fifthhorseman.net wrote:
 the signature-verification branch on my git repo [0] contains functional
 PGP/MIME signature verification if you supply the --verify argument to
 
  notmuch show --format=json

Daniel, this is really incredible.  I can't tell you how much I
appreciate all of your effort on this front.  This is really a very
fundamental improvement to this tool.  I can't wait to test it out!

jamie.


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

Inconsistent output from "notmuch search --output="

[Jameson Rollins]

On Wed, 24 Nov 2010 11:40:46 -0800, Carl Worth  wrote:
> So my inclination is to remove the prefixes and then recommend that you
> do:
> 
>   notmuch search --output=threads | sed -e 's/^/thread:'
> 
> in your script.

Hey, Carl.  I think that's reasonable.

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

Re: Inconsistent output from notmuch search --output=foo

[Jameson Rollins]

On Wed, 24 Nov 2010 11:40:46 -0800, Carl Worth cwo...@cworth.org wrote:
 So my inclination is to remove the prefixes and then recommend that you
 do:
 
   notmuch search --output=threads | sed -e 's/^/thread:'
 
 in your script.

Hey, Carl.  I think that's reasonable.

jamie.


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

Inconsistent output from "notmuch search --output="

[Jameson Rollins]

On Tue, 23 Nov 2010 18:09:03 -0800, Carl Worth  wrote:
> I think the right answer is to drop those prefixes in the output. Does
> anybody disagree? Does anyone have any scripts that are already
> consuming the output of "notmuch search --output=threads" or "notmuch
> search --output=messages" yet?

Hey, Carl.  I feel like those output options are most useful for
constructing new search strings.  If the prefixes were removed, one
would have to add them back when creating search strings from the
output.  I don't appear to currently be using any of the prefixed output
in scripts, but I have definitely used it to copy and paste threads and
ids for searches.  I guess I sort of think of this output as parallel to
the emacs show-stash-map.

I'm sure I could get used to a change, though.

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

C coding conventions for notmuch

[Jameson Rollins]

On Tue, 23 Nov 2010 13:48:40 -0500, Daniel Kahn Gillmor  wrote:
> attached is a .dir-locals.el file; placed in the root of the notmuch
> source tree, it makes emacs pick the default coding style (at least,
> using the style i see in notmuch-show.c today).

On Tue, 23 Nov 2010 18:39:07 -0600, Rob Browning  
wrote:
> Carl also suggested he might want to folow "linux" style in general, so
> perhaps:

You guys should just send these as patches.  Seems like it would be a
good idea to me just to keep this file with the source.

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

Handling PATCH from notmuchmail

[Jameson Rollins]

On Tue, 23 Nov 2010 15:47:26 +0100, Sebastian Spaeth  
wrote:
> On Mon, 22 Nov 2010 22:49:15 +0100, Xavier Maillard  wrote:
> > out of curiosity, how hackers on this mailing list and using notmuch
> > (through GNU Emacs client if at all) do handle all the patches sent here
> 
> cF to stash the filename and
> then switch to shell and do 
> git am -3 ctrl-shift-v RET

notmuch show --format=mbox id:XXX | git am

works well too, as does 

notmuch show --format=mbox thread:XXX | git am

for a whole series.

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

Re: Handling PATCH from notmuchmail

[Jameson Rollins]

On Tue, 23 Nov 2010 15:47:26 +0100, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 On Mon, 22 Nov 2010 22:49:15 +0100, Xavier Maillard x...@gnu.org wrote:
  out of curiosity, how hackers on this mailing list and using notmuch
  (through GNU Emacs client if at all) do handle all the patches sent here
 
 cF to stash the filename and
 then switch to shell and do 
 git am -3 ctrl-shift-v RET

notmuch show --format=mbox id:XXX | git am

works well too, as does 

notmuch show --format=mbox thread:XXX | git am

for a whole series.

jamie.


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

Re: C coding conventions for notmuch

[Jameson Rollins]

On Tue, 23 Nov 2010 13:48:40 -0500, Daniel Kahn Gillmor 
d...@fifthhorseman.net wrote:
 attached is a .dir-locals.el file; placed in the root of the notmuch
 source tree, it makes emacs pick the default coding style (at least,
 using the style i see in notmuch-show.c today).

On Tue, 23 Nov 2010 18:39:07 -0600, Rob Browning r...@defaultvalue.org wrote:
 Carl also suggested he might want to folow linux style in general, so
 perhaps:

You guys should just send these as patches.  Seems like it would be a
good idea to me just to keep this file with the source.

jamie.


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

Re: Inconsistent output from notmuch search --output=foo

[Jameson Rollins]

On Tue, 23 Nov 2010 18:09:03 -0800, Carl Worth cwo...@cworth.org wrote:
 I think the right answer is to drop those prefixes in the output. Does
 anybody disagree? Does anyone have any scripts that are already
 consuming the output of notmuch search --output=threads or notmuch
 search --output=messages yet?

Hey, Carl.  I feel like those output options are most useful for
constructing new search strings.  If the prefixes were removed, one
would have to add them back when creating search strings from the
output.  I don't appear to currently be using any of the prefixed output
in scripts, but I have definitely used it to copy and paste threads and
ids for searches.  I guess I sort of think of this output as parallel to
the emacs show-stash-map.

I'm sure I could get used to a change, though.

jamie.


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

notmuch release 0.5 now available

[Jameson Rollins]

On Mon, 22 Nov 2010 23:59:23 +0100, Xavier Maillard  wrote:
> On Mon, 22 Nov 2010 17:03:35 -0500, Jameson Rollins  finestructure.net> wrote:
> > "Fcc" means something like "file cc", which means that a copy of the
> > message is written to a local directory when sending.  This is useful
> > for keeping copies of all of the mail that you send out.
> 
> What is the advantage over the "Sent" IMAP folder ?

My sendmail program doesn't know anything about IMAP, so I have no such
folder.  I think it just depends on how your set up works.  If your sent
mail is already being archived somewhere, then maybe the Fcc isn't
useful for you.

jamie.
-- 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/20101122/36f42dbf/attachment.pgp>

notmuch release 0.5 now available

[Jameson Rollins]

On Mon, 22 Nov 2010 22:38:00 +0100, Xavier Maillard  
wrote:
> I am not sure I understand what Fcc and I'd be happy someone is
> explaining this to me :)

"Fcc" means something like "file cc", which means that a copy of the
message is written to a local directory when sending.  This is useful
for keeping copies of all of the mail that you send out.

> I still need a quick wayt to bounce messages though :D

I think you can do this with the "message-bounce" function in emacs.

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

Re: notmuch release 0.5 now available

[Jameson Rollins]

On Mon, 22 Nov 2010 22:38:00 +0100, Xavier Maillard xav...@maillard.im wrote:
 I am not sure I understand what Fcc and I'd be happy someone is
 explaining this to me :)

Fcc means something like file cc, which means that a copy of the
message is written to a local directory when sending.  This is useful
for keeping copies of all of the mail that you send out.

 I still need a quick wayt to bounce messages though :D

I think you can do this with the message-bounce function in emacs.

jamie.


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

Re: notmuch release 0.5 now available

[Jameson Rollins]

On Mon, 22 Nov 2010 23:59:23 +0100, Xavier Maillard x...@gnu.org wrote:
 On Mon, 22 Nov 2010 17:03:35 -0500, Jameson Rollins 
 jroll...@finestructure.net wrote:
  Fcc means something like file cc, which means that a copy of the
  message is written to a local directory when sending.  This is useful
  for keeping copies of all of the mail that you send out.
 
 What is the advantage over the Sent IMAP folder ?

My sendmail program doesn't know anything about IMAP, so I have no such
folder.  I think it just depends on how your set up works.  If your sent
mail is already being archived somewhere, then maybe the Fcc isn't
useful for you.

jamie.


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

a proposed change to JSON output to report verification of PGP/MIME signatures.

[Jameson Rollins]

On Tue, 16 Nov 2010 15:22:49 -0500, Daniel Kahn Gillmor  wrote:
> For clients that do not know how to interpret/display the verification
> results, i don't want the backend to incur the cost of verification that
> will be thrown away.

Aren't clients going to have to interpret/display the output regardless
of it's been verified or not?  It seems to me that understanding how to
display the verified output is really not that much more difficult than
understanding how to display the unverified output.

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

[PATCH] emacs: add some convenience functions to show mode

[Jameson Rollins]

On Tue, 16 Nov 2010 11:35:31 -0800, Carl Worth  wrote:
> These look fairly handy.
> 
> But, since I know our current keybindings are less-than-perfect, I would
> prefer to see patches that also fix them, (rather than just adding
> functionality that new users can't get at without manual customization).
> 
> Would you accept an invitation to make a proposal (with patch) to
> actually improve the default keybindings here as well?

Hey, Carl.  I could do this, but I think I would ultimately just be
submitting patches for notmuch to behave in the specific way that I want
it to behave.  I'm pretty sure that everyone has different ideas of what
they want, and I worry that if I start submitting my preference we'll
have to contend with lots of debate over behavior preference, leading to
lots of requests for more configuration options.  This has actually
already happened, most recently with my patch to remove thread archiving

a proposed change to JSON output to report verification of PGP/MIME signatures.

[Jameson Rollins]

On Tue, 16 Nov 2010 11:47:13 -0800, Carl Worth  wrote:
> The only other piece I think I'd like to see is actually making the
> content of the signature pieces available in the json output. Then, a
> client could do its own verification.
> 
> Then if we had that would we not want to add the --verify support into
> notmuch? (My guess is that we still would want it.)

Hey, Carl.  I think your suggestion to include the signatures in the
output is a reasonable.  However, (I could be misunderstanding your
suggestion but) I really think the Right thing is for notmuch to do the
verification itself.  I would almost say that --verify should be the
default, with a --no-verify option.  It will make things much easier for
all the UIs if notmuch handles the verification and just outputs the
result.

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

`notmuch setup` replaces `~/.notmuch-config` instead of truncating it

[Jameson Rollins]

On Tue, 16 Nov 2010 15:33:30 +0200, "Ciprian Dorin, Craciun"  wrote:
> But in my particular case `~/.notmuch-config` is symlinked to an
> applications configuration directory which is versioned. Thus I've
> expected than when notmuch updates the config, it opens it for
> read-write, but with the truncation flag (which as a consequence would
> have modified the symlinked file). But instead it deleted the symlink,
> and replaced it with a newly created file (thus breaking my custom
> configuration backup system.)
> 
> So my question is: is this behaviour (of deleting the file and
> creating a new one) deliberate? If not, could it be fixed (I could
> provide a patch) to just update the file in place?

Hi, Ciprian.  I had not noticed this, but now that you mention it, I see
that the same thing happened to me.  This behavior is surely not
deliberate, and is definitely undesirable.  A patch would be welcome.

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

Re: `notmuch setup` replaces `~/.notmuch-config` instead of truncating it

[Jameson Rollins]

On Tue, 16 Nov 2010 15:33:30 +0200, Ciprian Dorin, Craciun 
ciprian.crac...@gmail.com wrote:
 But in my particular case `~/.notmuch-config` is symlinked to an
 applications configuration directory which is versioned. Thus I've
 expected than when notmuch updates the config, it opens it for
 read-write, but with the truncation flag (which as a consequence would
 have modified the symlinked file). But instead it deleted the symlink,
 and replaced it with a newly created file (thus breaking my custom
 configuration backup system.)
 
 So my question is: is this behaviour (of deleting the file and
 creating a new one) deliberate? If not, could it be fixed (I could
 provide a patch) to just update the file in place?

Hi, Ciprian.  I had not noticed this, but now that you mention it, I see
that the same thing happened to me.  This behavior is surely not
deliberate, and is definitely undesirable.  A patch would be welcome.

jamie.


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

Re: a proposed change to JSON output to report verification of PGP/MIME signatures.

[Jameson Rollins]

On Tue, 16 Nov 2010 11:47:13 -0800, Carl Worth cwo...@cworth.org wrote:
 The only other piece I think I'd like to see is actually making the
 content of the signature pieces available in the json output. Then, a
 client could do its own verification.
 
 Then if we had that would we not want to add the --verify support into
 notmuch? (My guess is that we still would want it.)

Hey, Carl.  I think your suggestion to include the signatures in the
output is a reasonable.  However, (I could be misunderstanding your
suggestion but) I really think the Right thing is for notmuch to do the
verification itself.  I would almost say that --verify should be the
default, with a --no-verify option.  It will make things much easier for
all the UIs if notmuch handles the verification and just outputs the
result.

jamie.


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

notmuchsync: handling of the deleted tag

[Jameson Rollins]

On Sun, 14 Nov 2010 17:23:57 -0800, Jeff Richards  wrote:
> Having just switched from notmuchsync the synchronizing power of 0.5 and
> being as how I'm missing the pruning feature I gave this a try and found
> that I ended up with rm complaining that the file name length being too
> long or simply file not found.  Seems like the  
> xargs -0 rm 
> portion was choking as all the file names were being contcatenated.
> Perhaps the null character line ending is missing?  At this point I
> haven't investigated further.

I think the 'print0' might have been a mistake on Carl's part.  I don't
think that option is actually supported by notmuch.  In which case xargs
-0 isn't going to work as expected because there are no null characters
in the input stream to use as delimiters.

> So for anyone else who is stuck adjusting the one liner like 
> notmuch search --output=files tag:deleted -print0 | xargs -d '\n' rm

This is working because the input stream is newline delimited.  So I
think the -print0 is confusing the issue.

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

notmuchsync: handling of the deleted tag

[Jameson Rollins]

On Fri, 12 Nov 2010 16:52:51 -0800, Carl Worth  wrote:
> This one is a simple one-liner as of notmuch 0.4:
> 
> notmuch search --output=files tag:deleted -print0 | xargs -0 rm

Is -print0 actually a command that notmuch accepts?  It's not documented
as far as I can tell.  And it doesn't seem to affect the output of the
command, i.e. whether or not it's used the output is still newline
delimited.  I'm not seeing it in the source either.

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

Web archive (was: Combining threads)

[Jameson Rollins]

On Sun, 14 Nov 2010 23:21:26 +0100, Michal Sojka  wrote:
> Gmane is not good? I'm quite satisfied with the following in my .emacs:
> 
> (defun notmuch-show-stash-gmane ()
>   "Copy a link to gmane archive of the current message to kill-ring."
>   (interactive)
>   (notmuch-common-do-stash
>(concat "http://mid.gmane.org/;
>  (replace-regexp-in-string
>   "^id:\"\\(.*\\)\"$" "\\1" (notmuch-show-get-message-id))
> 

Hey, Michal.  Nice tip.

> (add-hook 'notmuch-show-hook
> (lambda () 
>   (define-key notmuch-show-stash-map "g" 'notmuch-show-stash-gmane)))

For what it's worth, I think you can accomplish this my simply adding
the following to your emacs config (assuming you've already loaded
notmuch):

(define-key notmuch-show-stash-map "g" 'notmuch-show-stash-gmane)

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

notmuchsync: handling of the deleted tag

[Jameson Rollins]

On Sun, 14 Nov 2010 23:21:41 +0100, Sebastian Spaeth  
wrote:
> > This one is a simple one-liner as of notmuch 0.4:
> > 
> > notmuch search --output=files tag:deleted -print0 | xargs -0 rm
> 
> Uhh, that is a neat line, and a neat trick. (is it on the emacstips page
> already? ;-))

It's not an emacs-specific tip!  I guess the web page needs a "general
tips" section...

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

[PATCH] emacs: add some convenience functions to show mode

[Jameson Rollins]

Adding three new conveneince functions:

notmuch-show-next-open-message-or-pop
notmuch-show-next-thread
notmuch-show-previous-thread

While these are not currently bound to any keys, I have found them to
be very useful for constructing custom key bindings outside of what
notmuch provides by default.  For example:

(define-key notmuch-show-mode-map "a"
  (lambda ()
"archive current message and advance"
(interactive)
(notmuch-show-remove-tag "inbox")
(notmuch-show-next-open-message-or-pop)))
(define-key notmuch-show-mode-map "N" 'notmuch-show-next-thread)
(define-key notmuch-show-mode-map "P" 'notmuch-show-previous-thread)
---
 emacs/notmuch-show.el |   39 +++
 1 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index b89b685..820fd0e 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -920,6 +920,45 @@ any effects from previous calls to
   (notmuch-show-mark-read)
   (notmuch-show-message-adjust))

+(defun notmuch-show-next-open-message-or-pop ()
+  "Show the next message or pop out if none remain."
+  (interactive)
+  (let (r)
+(while (and (setq r (notmuch-show-goto-message-next))
+   (not (notmuch-show-message-visible-p
+(if r
+   (progn
+ (notmuch-show-mark-read)
+ (notmuch-show-message-adjust))
+  (let ((parent-buffer notmuch-show-parent-buffer))
+   (if parent-buffer
+   (progn
+ (kill-this-buffer)
+ (switch-to-buffer parent-buffer)
+ (forward-line 1)))
+
+(defun notmuch-show-next-thread ()
+  "Move to the next thread from the last search."
+  (interactive)
+  (let ((parent-buffer notmuch-show-parent-buffer))
+(if parent-buffer
+  (progn
+(kill-this-buffer)
+(switch-to-buffer parent-buffer)
+(forward-line 1)
+(notmuch-search-show-thread)
+
+(defun notmuch-show-previous-thread ()
+  "Move to the previous thread from the last search."
+  (interactive)
+  (let ((parent-buffer notmuch-show-parent-buffer))
+(if parent-buffer
+  (progn
+(kill-this-buffer)
+(switch-to-buffer parent-buffer)
+(forward-line -1)
+(notmuch-search-show-thread)
+
 (defun notmuch-show-view-raw-message ()
   "View the file holding the current message."
   (interactive)
-- 
1.7.2.3

[PATCH] How to improve the mail handling workflow?

[Jameson Rollins]

On Sun, 14 Nov 2010 22:07:03 +0100, Sebastian Spaeth  
wrote:
> This only works if you've already loaded notmuch, or you get error
> messages about notmuch-search-mode-map not being known. How do you deal
> with that or does it simply work for you?

I have:

(require 'notmuch)

in my config file before I add these keybinding.

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