Emacs: Crypto: How to get automatic encryption?

[micah anderson]

On Tue, 17 Jan 2012 09:19:51 +, David Edmondson  wrote:
> On Mon, 16 Jan 2012 23:48:30 -0500, Antoine Beaupr?  anarcat.ath.cx> wrote:
> > Jumping in here, I have modified the previously posted code here to
> > provide me with a more complete solution.
> 
> This looks good. I'll switch over to using it.
> 
> > Code is attached. Obviously, those function names would change if they
> > would be to integrate into notmuch. ;)
> 
> I wondered about pushing to have notmuch do this by default. In general
> I like the idea, but it suffers if a recipient occasionally uses a mail
> client that does not support decryption (phone, PDA, webmail, ...).

It seems like the original message has not made it through the list
moderation still. 

David replied to it because it was sent to him, but the list email
hasn't come through yet (I want this functionality, so I'm dying to see
the patch!)

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

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

[micah anderson]

On Tue, 17 Jan 2012 09:19:51 +, David Edmondson d...@dme.org wrote:
 On Mon, 16 Jan 2012 23:48:30 -0500, Antoine Beaupré anar...@anarcat.ath.cx 
 wrote:
  Jumping in here, I have modified the previously posted code here to
  provide me with a more complete solution.
 
 This looks good. I'll switch over to using it.
 
  Code is attached. Obviously, those function names would change if they
  would be to integrate into notmuch. ;)
 
 I wondered about pushing to have notmuch do this by default. In general
 I like the idea, but it suffers if a recipient occasionally uses a mail
 client that does not support decryption (phone, PDA, webmail, ...).

It seems like the original message has not made it through the list
moderation still. 

David replied to it because it was sent to him, but the list email
hasn't come through yet (I want this functionality, so I'm dying to see
the patch!)

micah


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

release-candidate/0.6

[micah anderson]

On Fri, 06 May 2011 12:46:34 -0700, Jameson Graef Rollins  wrote:
>
> I might try to add a couple of more things before declaring the
> candidate release-ready, but this is more-or-less it.  Please start
> using this branch "in production" as much as possible, so that we can
> build up a chorus of support for pushing this release out.  Once you
> have build, tested, and started using the branch, please reply to this
> email thread to express your support for it's release.

I've been using this branch now for a couple of days and its solid,
thanks for pulling this together Mr. Rollins.

> The release-candidate/0.6 branch also includes debian package updates,
> so you should be able to easily build debian packages from the branch:
> 
> git buildpackage -uc -us --git-ignore-branch

I used this mechanism to build a package and install it, it worked
well. I also ran lintian on it just to see if there were any issues, but
you get an A+.

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

Re: release-candidate/0.6

[micah anderson]

On Fri, 06 May 2011 12:46:34 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:

 I might try to add a couple of more things before declaring the
 candidate release-ready, but this is more-or-less it.  Please start
 using this branch in production as much as possible, so that we can
 build up a chorus of support for pushing this release out.  Once you
 have build, tested, and started using the branch, please reply to this
 email thread to express your support for it's release.

I've been using this branch now for a couple of days and its solid,
thanks for pulling this together Mr. Rollins.

 The release-candidate/0.6 branch also includes debian package updates,
 so you should be able to easily build debian packages from the branch:
 
 git buildpackage -uc -us --git-ignore-branch

I used this mechanism to build a package and install it, it worked
well. I also ran lintian on it just to see if there were any issues, but
you get an A+.

micah


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

Org-mode support

[micah anderson]

On Thu, 17 Mar 2011 00:28:30 +0100, Matthieu Lemerre  wrote:

> > I have one question, how do you add multiple query arguments? For
> > example, in my org file I tried 'notmuch-search:tag:notmuch' - this
> > worked great, but if I did 'notmuch-search:tag:notmuch and subject:Org'
> > the link only works up until the first space.
> 
> This is because org-mode links must be url encoded (this is a org-mode
> limitation, could do nothing about it). So in links that contain spaces,
> such as yours, spaces must be replaced by %20, like this:
> 
> [[notmuch-search:toto%20and%20tata][Notmuch search: toto and tata]]

Thanks, I'm somewhat new to org-mode, so I appreciate that information!

> > I also noticed that David Bremner has done something similar[0] and I
> > wonder if you have looked at his code[1], or if David has looked at
> > yours. Perhaps the start of a collaboration?
> 
> If I remember correctly, I specifically forbid myself to look into this
> code because David had copyright issues with its employer. But I believe
> that both codes are doing essentially the same thing.

It sounds like you are right about the copyright issues. 

I noticed one thing about your org add-on that would be nice to improve:
it doesn't appear as if you support linking to a thread in
notmuch-search-mode. If I have a search buffer, generated by "notmuch
search tag:notmuch" and I find in there your message with the Subject
"Org-mode support" and I put my cursor on it and do M-x org-store-link,
the link that is generated is to "Notmuch search: tag:notmuch" rather
than to the thread id that is under the cursor. A minor thing, but could
be quite useful.

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

Org-mode support

[micah anderson]

Hi Matthieu!

On Mon, 07 Feb 2011 22:22:17 +0100, Matthieu Lemerre  wrote:
> I have written the org-mode support for notmuch a while ago. It allows
> to open links to notmuch from org-mode and create org-mode link from
> notmuch buffers.
> 
> The current maintainer of the package is looking for feedback for
> inclusion of the package in the org-mode trunk, so if anyone is using
> org-mode, I think it would be a good idea to say so on the orgmode
> mailing list!

Thanks so much for sending this, its very interesting! I've just started
trying it and have managed to use M-x org-store-link on your email to
add an org-mode todo item to try out org-mode support for notmuch :)

I have one question, how do you add multiple query arguments? For
example, in my org file I tried 'notmuch-search:tag:notmuch' - this
worked great, but if I did 'notmuch-search:tag:notmuch and subject:Org'
the link only works up until the first space.

I also noticed that David Bremner has done something similar[0] and I
wonder if you have looked at his code[1], or if David has looked at
yours. Perhaps the start of a collaboration?

Micah

0. id:1259979997-31544-1-git-send-email-david at tethera.net
1. 
http://pivot.cs.unb.ca/git/?p=org-mode.git;a=shortlog;h=refs/heads/notmuch-link
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: Org-mode support

[micah anderson]

Hi Matthieu!

On Mon, 07 Feb 2011 22:22:17 +0100, Matthieu Lemerre ra...@free.fr wrote:
 I have written the org-mode support for notmuch a while ago. It allows
 to open links to notmuch from org-mode and create org-mode link from
 notmuch buffers.
 
 The current maintainer of the package is looking for feedback for
 inclusion of the package in the org-mode trunk, so if anyone is using
 org-mode, I think it would be a good idea to say so on the orgmode
 mailing list!

Thanks so much for sending this, its very interesting! I've just started
trying it and have managed to use M-x org-store-link on your email to
add an org-mode todo item to try out org-mode support for notmuch :)

I have one question, how do you add multiple query arguments? For
example, in my org file I tried 'notmuch-search:tag:notmuch' - this
worked great, but if I did 'notmuch-search:tag:notmuch and subject:Org'
the link only works up until the first space.

I also noticed that David Bremner has done something similar[0] and I
wonder if you have looked at his code[1], or if David has looked at
yours. Perhaps the start of a collaboration?

Micah

0. id:1259979997-31544-1-git-send-email-da...@tethera.net
1. 
http://pivot.cs.unb.ca/git/?p=org-mode.git;a=shortlog;h=refs/heads/notmuch-link


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

new "crypto" branch providing full PGP/MIME support

[micah anderson]

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.

Yes, that is true. However, I still think the default should be
on. Especially considering all three people (myself included) who I've
seen try this have been puzzled by why it wasn't working and had to be
told that they needed to turn it on.

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

If I open a message that was sent to me and was encrypted by the sender
using a key that they have since revoked, or has expired, I saw this.

> > 5. unknown keys are represented in a long format,
> > eg. '0x5585F58CC827A062' when most tools represent them just with their
> > shortened keyid (in this case this one would be: 0xC827A062), is there a
> > particular reason for this?
> 
> Short keyIDs are easily spoofable; believing anything based on a matched
> short keyID is a mistake. 

Most humans I know reference their key by the keyid, where keyid means
the 8 character representation of their key. When they need to ensure
that their key is not being spoofed they either rely on the tools to do
cryptographic verification, or inspect the fingerprint. I dont think
moving towards using a longer format of the keyid helps here. The key is
unknown, and to get it known requires going through a key signing
process, or fingerprint verification, which isn't aided by having a
longer form keyid. 

If I am presented with a short form keyid, and I go and try and receive
that key from the keyservers and then I am presented with two different
options, then I'm going to inspect the two and determine then which one
is the right one. I dont need to front-load that knowledge in the
interface.

> > I recognize some people's keyids in the
> > short form, but do not in the longform.
> 
> You can derive the short form from the long form by ignoring
> everything but the last 8 hex characters.

Yes, I know that, but my brain parser looks at '0x5585F58CC827A062' and
has to squint to try and ignore the last 8 characters. In fact, its
often quicker for me to use my cursor to go up there and count backwards
8 characters and then hit a space so I can visually separate it. Visual
interface parse failure with long form.

> But if you actually recognize the short form, i'd expect you to have
> the relevant key in your keyring;

Not always true. In fact the parse error I was discussing above was
about a key I used to use, but have removed from my keyring, and my
secret keyring. In the long form, I did *not* recognize it. If it were
simply 1CF2D62A I would have instantly recognized it as my old key that
I've revoked.

> is this really a use case worth bothering with?

No.

> do you have a suggestion for how you think it should behave
> differently?

I think my suggestion was already made: short form.

m
-- 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/d3180abd/attachment.pgp>

Re: new crypto branch providing full PGP/MIME support

[micah anderson]

On Thu, 03 Feb 2011 14:52:01 -0500, Daniel Kahn Gillmor 
d...@fifthhorseman.net 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.

Yes, that is true. However, I still think the default should be
on. Especially considering all three people (myself included) who I've
seen try this have been puzzled by why it wasn't working and had to be
told that they needed to turn it on.

  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?

If I open a message that was sent to me and was encrypted by the sender
using a key that they have since revoked, or has expired, I saw this.

  5. unknown keys are represented in a long format,
  eg. '0x5585F58CC827A062' when most tools represent them just with their
  shortened keyid (in this case this one would be: 0xC827A062), is there a
  particular reason for this?
 
 Short keyIDs are easily spoofable; believing anything based on a matched
 short keyID is a mistake. 

Most humans I know reference their key by the keyid, where keyid means
the 8 character representation of their key. When they need to ensure
that their key is not being spoofed they either rely on the tools to do
cryptographic verification, or inspect the fingerprint. I dont think
moving towards using a longer format of the keyid helps here. The key is
unknown, and to get it known requires going through a key signing
process, or fingerprint verification, which isn't aided by having a
longer form keyid. 

If I am presented with a short form keyid, and I go and try and receive
that key from the keyservers and then I am presented with two different
options, then I'm going to inspect the two and determine then which one
is the right one. I dont need to front-load that knowledge in the
interface.

  I recognize some people's keyids in the
  short form, but do not in the longform.
 
 You can derive the short form from the long form by ignoring
 everything but the last 8 hex characters.

Yes, I know that, but my brain parser looks at '0x5585F58CC827A062' and
has to squint to try and ignore the last 8 characters. In fact, its
often quicker for me to use my cursor to go up there and count backwards
8 characters and then hit a space so I can visually separate it. Visual
interface parse failure with long form.

 But if you actually recognize the short form, i'd expect you to have
 the relevant key in your keyring;

Not always true. In fact the parse error I was discussing above was
about a key I used to use, but have removed from my keyring, and my
secret keyring. In the long form, I did *not* recognize it. If it were
simply 1CF2D62A I would have instantly recognized it as my old key that
I've revoked.

 is this really a use case worth bothering with?

No.

 do you have a suggestion for how you think it should behave
 differently?

I think my suggestion was already made: short form.

m


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

notmuch's idea of concurrency / failing an invocation

[micah anderson]

On Thu, 27 Jan 2011 12:35:16 -0800, Jameson Rollins  wrote:
> 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.

Sometimes I can have several thousand messages to add/remove from the
database. I know this is probably unusal, but for me its not due to
system emails. I suppose if I checked my email more frequently, I'd have
less to process on each run, but thats more side-stepping the
concurrency issue.

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

new "crypto" branch providing full PGP/MIME support

[micah anderson]

On Wed, 02 Feb 2011 17:18:45 -0800, Jameson Rollins  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:
> 
> * 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

Don't forget that you also included man page changes!

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

I've really really really wanted this functionality, so I pulled this
right away and have been testing it, its really slick! I like how the
emacs UI gives you good visual feedback for different signature states
(I had red for a signature from Sebastian Spaeth because I did not have
the key; orange for when I obtained that key; and green for Jameson and
dkg's mails because I have exchanged keys with them and have full
validity for them; and purple for a decryption error). The minor delay
in opening a thread with signatures is not bad, and is to be expected.

And messages that are PGP/MIME encrypted are decrypted automatically,
wow, this is amazing. I enthusiastically support merging this into
mainline for the next release.

I have a couple points of feedback that I do not think should hold up
merging this work:

1. I personally think notmuch-show-process-pgpmime should default to
true

2. in-line pgp messages don't have any processing done on them. getting
the mime-encoded processing work is a huge step and I'm happy that
works, in-line can (and IMHO, should) come later

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"

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?

5. unknown keys are represented in a long format,
eg. '0x5585F58CC827A062' when most tools represent them just with their
shortened keyid (in this case this one would be: 0xC827A062), is there a
particular reason for this? I recognize some people's keyids in the
short form, but do not in the longform.

6. this is awesome, huge thanks to everyone who has worked on this!

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

[micah anderson]

On Thu, 27 Jan 2011 12:35:16 -0800, Jameson Rollins 
jroll...@finestructure.net wrote:
 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.

Sometimes I can have several thousand messages to add/remove from the
database. I know this is probably unusal, but for me its not due to
system emails. I suppose if I checked my email more frequently, I'd have
less to process on each run, but thats more side-stepping the
concurrency issue.

micah


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

notmuch's idea of concurrency / failing an invocation

[micah anderson]

On Thu, 27 Jan 2011 19:20:00 +0100, Thomas Schwinge  
wrote:
> Stepping away from the current code base -- what is notmuch's original
> idea of concurrency?  That is, all of us probably know that one:
> 
> A Xapian exception occurred opening database: Unable to get write
>   lock on /home/thomas/Mail-schwinge.name-thomas/.notmuch/xapian:
>   already locked
> 
> I recently saw that one while using the Emacs UI (that one tried to
> remove a unread tag or similar), and in parallel a delivery to the
> notmuch DB was going on.

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. 

Usually, I switch to another task until my disk light has ceased being
solid, because the update time is too slow for me to wait. 

Now that folders are making it in, the two remaining features that are
driving me nuts with notmuch is this one and the
verification/decryption/encryption process (replying to an encrypted
message is 12 distinct steps for me, which is discouraging me from doing
that at all). 

I really don't want to complain, because I have no time to help in these
areas,  rather I'm interested  to know  if anyone  has any  pointers for
making this less annoying, and I'm  hoping that at some point I can free
up time to help. Perhaps I need to dump/restore my notmuch DB? Or index
less mail?

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

[micah anderson]

On Thu, 27 Jan 2011 19:20:00 +0100, Thomas Schwinge tho...@schwinge.name 
wrote:
 Stepping away from the current code base -- what is notmuch's original
 idea of concurrency?  That is, all of us probably know that one:
 
 A Xapian exception occurred opening database: Unable to get write
   lock on /home/thomas/Mail-schwinge.name-thomas/.notmuch/xapian:
   already locked
 
 I recently saw that one while using the Emacs UI (that one tried to
 remove a unread tag or similar), and in parallel a delivery to the
 notmuch DB was going on.

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. 

Usually, I switch to another task until my disk light has ceased being
solid, because the update time is too slow for me to wait. 

Now that folders are making it in, the two remaining features that are
driving me nuts with notmuch is this one and the
verification/decryption/encryption process (replying to an encrypted
message is 12 distinct steps for me, which is discouraging me from doing
that at all). 

I really don't want to complain, because I have no time to help in these
areas,  rather I'm interested  to know  if anyone  has any  pointers for
making this less annoying, and I'm  hoping that at some point I can free
up time to help. Perhaps I need to dump/restore my notmuch DB? Or index
less mail?

micah


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

[PATCH] Add NEWS updates for my last batch of patches

[micah anderson]

On Fri, 23 Apr 2010 10:42:31 -0700, Dirk Hohndel  
wrote:

> +Provide 'G' key binding to trigger mail refresh
> +
> +  The 'G' key works wherever '=' works. Before refreshing the screen
> +  it calls an external program that can be used to poll email servers,
> +  run notmuch new and setup specific tags for the new emails. The
> +  script to be called can be customized with. Use the customize screen

Strange sentence: "The script to be called can be customized with." 

I'd suggest an improvement, but I'm not sure what it should read.

micah


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

Re: [PATCH] Add NEWS updates for my last batch of patches

[micah anderson]

On Fri, 23 Apr 2010 10:42:31 -0700, Dirk Hohndel hohn...@infradead.org wrote:

 +Provide 'G' key binding to trigger mail refresh
 +
 +  The 'G' key works wherever '=' works. Before refreshing the screen
 +  it calls an external program that can be used to poll email servers,
 +  run notmuch new and setup specific tags for the new emails. The
 +  script to be called can be customized with. Use the customize screen

Strange sentence: The script to be called can be customized with. 

I'd suggest an improvement, but I'm not sure what it should read.

micah




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

"bouncing" messages

[micah anderson]

On Sun, 18 Apr 2010 22:06:39 +0200, Xavier Maillard  
wrote:
> On Fri, 16 Apr 2010 10:34:53 +0200, Peter Wiersig  london087.server4you.de> wrote:
> > On Thu, 15 Apr 2010 17:27:17 -0400, Jameson Rollins  > finestructure.net> wrote:
> > > Does anyone know how to "bounce" a message,
> > 
> > pipe the message to "sendmail user at axample.com"
> > 
> > Well, ok, mutt adds "Resent-*" headers to the bounced message, so there
> > it's not unaltered.
> 
> Kudos to you Peter, that will help me a lot too.

It would be great if this became a key to make this easier. In mutt,
that key is 'b', which prompts you who you should send the message
to. That key is already bound to showing the body in notmuch, but I'm
sure there are other options.

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

[PATCH 1/1] Stores the folder (directory name) of the message in the database as a term with folder prefix.

[Micah Anderson]

  This patch was originally sent by Andreas Kl?ckner in:
  id:200912141421.52561.lists at informa.tiker.net. It was then
  subsequently updated by Michal Sojka in:
  id:1264692317-9175-2-git-send-email-sojkam1 at fel.cvut.cz and then
  further improved again by Michal Sojka in:
  id:1265122868-12133-1-git-send-email-sojkam1 at fel.cvut.cz

  This is a rebase of the latest patch off of the current git HEAD.

. The differences from the original patch are:
  - Rebased off of current git HEAD
  - Folder name is taken from strings generated during travesal. It no
longer uses glib nor it allocates additional memory to determine the
base name. The same approach as in
id:87fx8bygi7.fsf at linux.vnet.ibm.com was used.
  - Removed unrelated change which was submitted separately as
id:1264691584-8290-2-git-send-email-sojkam1 at fel.cvut.cz
  - Changed the comment describing database schema.

TODO (see Carl's email: id:87zl5k0w6s.fsf at yoom.home.cworth.org):

  - Support hierarchical folders: this patch is only storing the final
directory component. This should be hooked in differently with
filename storage so the whole filename is indexed as text to
provide arbitrary search phrases such as "folder:'foo/bar/baz'"
---
 lib/database.cc |   13 +
 lib/notmuch.h   |1 +
 notmuch-new.c   |   39 +--
 3 files changed, 47 insertions(+), 6 deletions(-)

diff --git a/lib/database.cc b/lib/database.cc
index c91e97c..6364623 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -84,9 +84,9 @@ typedef struct {
  * MESSAGE_ID: The unique ID of the mail mess (see "id" above)
  *
  * In addition, terms from the content of the message are added with
- * "from", "to", "attachment", and "subject" prefixes for use by the
- * user in searching. But the database doesn't really care itself
- * about any of these.
+ * "from", "to", "attachment", "subject" and "folder" prefixes for use
+ * by the user in searching. But the database doesn't really care
+ * itself about any of these.
  *
  * The data portion of a mail document is empty.
  *
@@ -155,7 +155,8 @@ prefix_t PROBABILISTIC_PREFIX[]= {
 { "from",  "XFROM" },
 { "to","XTO" },
 { "attachment","XATTACHMENT" },
-{ "subject",   "XSUBJECT"}
+{ "subject",   "XSUBJECT"},
+{ "folder","XFOLDER"}
 };

 int
@@ -1362,6 +1363,7 @@ _notmuch_database_link_message (notmuch_database_t 
*notmuch,
 notmuch_status_t
 notmuch_database_add_message (notmuch_database_t *notmuch,
  const char *filename,
+ const char *folder_name,
  notmuch_message_t **message_ret)
 {
 notmuch_message_file_t *message_file;
@@ -1477,6 +1479,9 @@ notmuch_database_add_message (notmuch_database_t *notmuch,
date = notmuch_message_file_get_header (message_file, "date");
_notmuch_message_set_date (message, date);

+   if (folder_name != NULL)
+   _notmuch_message_gen_terms (message, "folder", folder_name);
+
_notmuch_message_index_file (message, filename);
} else {
ret = NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID;
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 88da078..ce81565 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -264,6 +264,7 @@ notmuch_database_get_directory (notmuch_database_t 
*database,
 notmuch_status_t
 notmuch_database_add_message (notmuch_database_t *database,
  const char *filename,
+ const char *folder_name,
  notmuch_message_t **message);

 /* Remove a message from the given notmuch database.
diff --git a/notmuch-new.c b/notmuch-new.c
index 44b50aa..6ad3c09 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -21,6 +21,7 @@
 #include "notmuch-client.h"

 #include 
+#include 

 typedef struct _filename_node {
 char *filename;
@@ -169,6 +170,35 @@ _entries_resemble_maildir (struct dirent **entries, int 
count)
 return 0;
 }

+static char*
+_get_folder_base_name(const char *path)
+{
+  gchar *full_folder_name = NULL;
+  gchar *folder_base_name = NULL;
+  
+  /* Find name of "folder" containing the email. */
+  full_folder_name = g_strdup(path);
+  while (1) {
+folder_base_name = g_path_get_basename(full_folder_name);
+
+if (strcmp(folder_base_name, "cur") == 0
+   || strcmp(folder_base_name, "new") == 0) {
+  gchar *parent_name = g_path_get_dirname(full_folder_name);
+  g_free(full_folder_name);
+  full_folder_name = parent_name;
+} else
+  break;
+  }
+  
+  g_free(full_folder_name);
+  
+  if (strcmp(folder_base_name, ".") == 0) {
+g_free(folder_base_name);
+folder_base_name = NULL;
+  }
+  return folder_base_name;
+}
+
 /* Examine 'path' recursively as follows:
  *
  *   o Ask the filesystem for the mtime of 'path' (fs_mtime)
@@ 

[PATCH 1/1] Stores the folder (directory name) of the message in the database as a term with folder prefix.

[Micah Anderson]

  This patch was originally sent by Andreas Klöckner in:
  id:200912141421.52561.li...@informa.tiker.net. It was then
  subsequently updated by Michal Sojka in:
  id:1264692317-9175-2-git-send-email-sojk...@fel.cvut.cz and then
  further improved again by Michal Sojka in:
  id:1265122868-12133-1-git-send-email-sojk...@fel.cvut.cz

  This is a rebase of the latest patch off of the current git HEAD.

. The differences from the original patch are:
  - Rebased off of current git HEAD
  - Folder name is taken from strings generated during travesal. It no
longer uses glib nor it allocates additional memory to determine the
base name. The same approach as in
id:87fx8bygi7@linux.vnet.ibm.com was used.
  - Removed unrelated change which was submitted separately as
id:1264691584-8290-2-git-send-email-sojk...@fel.cvut.cz
  - Changed the comment describing database schema.

TODO (see Carl's email: id:87zl5k0w6s@yoom.home.cworth.org):

  - Support hierarchical folders: this patch is only storing the final
directory component. This should be hooked in differently with
filename storage so the whole filename is indexed as text to
provide arbitrary search phrases such as folder:'foo/bar/baz'
---
 lib/database.cc |   13 +
 lib/notmuch.h   |1 +
 notmuch-new.c   |   39 +--
 3 files changed, 47 insertions(+), 6 deletions(-)

diff --git a/lib/database.cc b/lib/database.cc
index c91e97c..6364623 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -84,9 +84,9 @@ typedef struct {
  * MESSAGE_ID: The unique ID of the mail mess (see id above)
  *
  * In addition, terms from the content of the message are added with
- * from, to, attachment, and subject prefixes for use by the
- * user in searching. But the database doesn't really care itself
- * about any of these.
+ * from, to, attachment, subject and folder prefixes for use
+ * by the user in searching. But the database doesn't really care
+ * itself about any of these.
  *
  * The data portion of a mail document is empty.
  *
@@ -155,7 +155,8 @@ prefix_t PROBABILISTIC_PREFIX[]= {
 { from,  XFROM },
 { to,XTO },
 { attachment,XATTACHMENT },
-{ subject,   XSUBJECT}
+{ subject,   XSUBJECT},
+{ folder,XFOLDER}
 };
 
 int
@@ -1362,6 +1363,7 @@ _notmuch_database_link_message (notmuch_database_t 
*notmuch,
 notmuch_status_t
 notmuch_database_add_message (notmuch_database_t *notmuch,
  const char *filename,
+ const char *folder_name,
  notmuch_message_t **message_ret)
 {
 notmuch_message_file_t *message_file;
@@ -1477,6 +1479,9 @@ notmuch_database_add_message (notmuch_database_t *notmuch,
date = notmuch_message_file_get_header (message_file, date);
_notmuch_message_set_date (message, date);
 
+   if (folder_name != NULL)
+   _notmuch_message_gen_terms (message, folder, folder_name);
+
_notmuch_message_index_file (message, filename);
} else {
ret = NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID;
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 88da078..ce81565 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -264,6 +264,7 @@ notmuch_database_get_directory (notmuch_database_t 
*database,
 notmuch_status_t
 notmuch_database_add_message (notmuch_database_t *database,
  const char *filename,
+ const char *folder_name,
  notmuch_message_t **message);
 
 /* Remove a message from the given notmuch database.
diff --git a/notmuch-new.c b/notmuch-new.c
index 44b50aa..6ad3c09 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -21,6 +21,7 @@
 #include notmuch-client.h
 
 #include unistd.h
+#include glib.h
 
 typedef struct _filename_node {
 char *filename;
@@ -169,6 +170,35 @@ _entries_resemble_maildir (struct dirent **entries, int 
count)
 return 0;
 }
 
+static char*
+_get_folder_base_name(const char *path)
+{
+  gchar *full_folder_name = NULL;
+  gchar *folder_base_name = NULL;
+  
+  /* Find name of folder containing the email. */
+  full_folder_name = g_strdup(path);
+  while (1) {
+folder_base_name = g_path_get_basename(full_folder_name);
+
+if (strcmp(folder_base_name, cur) == 0
+   || strcmp(folder_base_name, new) == 0) {
+  gchar *parent_name = g_path_get_dirname(full_folder_name);
+  g_free(full_folder_name);
+  full_folder_name = parent_name;
+} else
+  break;
+  }
+  
+  g_free(full_folder_name);
+  
+  if (strcmp(folder_base_name, .) == 0) {
+g_free(folder_base_name);
+folder_base_name = NULL;
+  }
+  return folder_base_name;
+}
+
 /* Examine 'path' recursively as follows:
  *
  *   o Ask the filesystem for the mtime of 'path' (fs_mtime)
@@ -222,6 +252,7 @@ add_files_recursive (notmuch_database_t 

Plans for the 0.2 release (this week)

[micah anderson]

On 2010-04-08, micah anderson wrote:
> On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth  wrote:
> > For the upcoming 0.2 release, here are some things that I would like to
> > have in place:
> > 
> >   * Changes to indexing, (addition of body:, folder:, list:, etc.). This
> > is stuff that I'll work on.
> 
> Also, fwiw, the folder: indexing is probably the new feature that I'm
> most eagerly awaiting.  I've got all these ideas for ways to handle sent
> mail and drafts if we can get this working.

+1 on folder: capability!

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

Re: Plans for the 0.2 release (this week)

[micah anderson]

On 2010-04-08, micah anderson wrote:
 On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth cwo...@cworth.org wrote:
  For the upcoming 0.2 release, here are some things that I would like to
  have in place:
  
* Changes to indexing, (addition of body:, folder:, list:, etc.). This
  is stuff that I'll work on.
 
 Also, fwiw, the folder: indexing is probably the new feature that I'm
 most eagerly awaiting.  I've got all these ideas for ways to handle sent
 mail and drafts if we can get this working.

+1 on folder: capability!

micah


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

[notmuch] [Sebastian Spaeth] Pull requests

[micah anderson]

On 2010-03-27, micah anderson wrote:
> On Thu, 25 Mar 2010 22:50:52 -0400, micah anderson  
> wrote:
> > On Mon, 01 Mar 2010 15:57:00 +0100, "Sebastian Spaeth"  > SSpaeth.de> wrote:
> > 
> > > From git repository git://github.com/spaetz/notmuch-all-feature.git I
> > > would like to advocate the following branches for quick pulling. Each
> > > contains 1 or 2 patches. They have all been based on todays
> > > cworth/master, so it should be really painless.
> > 
> > Thanks for pulling these all together! All the ones that you propose I
> > also use and would really like these to be merged as well.
> > 
> > The only other patch that I find absolutely crucial, that you do not
> > include, is the 'Preserve folder information when indexing' patch which,
> > although not perfect, does significantly change my life. 
> 
> Glad you find it useful. Yes, having the folder information would indeed
> be nice. Is that patch working well for you? (Can you point me to the
> mail ID of the patch you are using? There have been several versions
> around).

The patch works really well for me. I also had difficulty figuring out
which was the latest. The thread is
thread:4ca0710d708e648c214ba3a67469f5bd, and the Message-ID is:
1265122868-12133-1-git-send-email-sojkam1 at fel.cvut.cz

I had to rebase the patch to get it to apply with the other features
that you have in your branch. I'm attaching that rebased patch to this
message.




-- 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/20100407/c33b4278/attachment.pgp>
-- next part --
A non-text attachment was scrubbed...
Name: folder.diff
Type: text/x-diff
Size: 4412 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100407/c33b4278/attachment.diff>

Re: [notmuch] [Sebastian Spaeth] Pull requests

[micah anderson]

On 2010-03-27, micah anderson wrote:
 On Thu, 25 Mar 2010 22:50:52 -0400, micah anderson mi...@riseup.net wrote:
  On Mon, 01 Mar 2010 15:57:00 +0100, Sebastian Spaeth 
  sebast...@sspaeth.de wrote:
  
   From git repository git://github.com/spaetz/notmuch-all-feature.git I
   would like to advocate the following branches for quick pulling. Each
   contains 1 or 2 patches. They have all been based on todays
   cworth/master, so it should be really painless.
  
  Thanks for pulling these all together! All the ones that you propose I
  also use and would really like these to be merged as well.
  
  The only other patch that I find absolutely crucial, that you do not
  include, is the 'Preserve folder information when indexing' patch which,
  although not perfect, does significantly change my life. 
 
 Glad you find it useful. Yes, having the folder information would indeed
 be nice. Is that patch working well for you? (Can you point me to the
 mail ID of the patch you are using? There have been several versions
 around).

The patch works really well for me. I also had difficulty figuring out
which was the latest. The thread is
thread:4ca0710d708e648c214ba3a67469f5bd, and the Message-ID is:
1265122868-12133-1-git-send-email-sojk...@fel.cvut.cz

I had to rebase the patch to get it to apply with the other features
that you have in your branch. I'm attaching that rebased patch to this
message.






pgpjTfePIOaPP.pgp
Description: PGP signature
commit 91e11a2a406683f1f80e19334da8124a25ec89fe
Author: Micah Anderson mi...@riseup.net
Date:   Thu Mar 25 23:07:10 2010 -0400

add folder patch, rebased

diff --git a/lib/database.cc b/lib/database.cc
index c91e97c..6364623 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -84,9 +84,9 @@ typedef struct {
  *	MESSAGE_ID:	The unique ID of the mail mess (see id above)
  *
  * In addition, terms from the content of the message are added with
- * from, to, attachment, and subject prefixes for use by the
- * user in searching. But the database doesn't really care itself
- * about any of these.
+ * from, to, attachment, subject and folder prefixes for use
+ * by the user in searching. But the database doesn't really care
+ * itself about any of these.
  *
  * The data portion of a mail document is empty.
  *
@@ -155,7 +155,8 @@ prefix_t PROBABILISTIC_PREFIX[]= {
 { from,			XFROM },
 { to,			XTO },
 { attachment,		XATTACHMENT },
-{ subject,		XSUBJECT}
+{ subject,		XSUBJECT},
+{ folder, 		XFOLDER}
 };
 
 int
@@ -1362,6 +1363,7 @@ _notmuch_database_link_message (notmuch_database_t *notmuch,
 notmuch_status_t
 notmuch_database_add_message (notmuch_database_t *notmuch,
 			  const char *filename,
+			  const char *folder_name,
 			  notmuch_message_t **message_ret)
 {
 notmuch_message_file_t *message_file;
@@ -1477,6 +1479,9 @@ notmuch_database_add_message (notmuch_database_t *notmuch,
 	date = notmuch_message_file_get_header (message_file, date);
 	_notmuch_message_set_date (message, date);
 
+	if (folder_name != NULL)
+		_notmuch_message_gen_terms (message, folder, folder_name);
+
 	_notmuch_message_index_file (message, filename);
 	} else {
 	ret = NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID;
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 0d9cb0f..e475072 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -263,6 +263,7 @@ notmuch_database_get_directory (notmuch_database_t *database,
 notmuch_status_t
 notmuch_database_add_message (notmuch_database_t *database,
 			  const char *filename,
+			  const char *folder_name,
 			  notmuch_message_t **message);
 
 /* Remove a message from the given notmuch database.
diff --git a/notmuch-new.c b/notmuch-new.c
index 93da1d7..394d76c 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -21,6 +21,7 @@
 #include notmuch-client.h
 
 #include unistd.h
+#include glib.h
 
 typedef struct _filename_node {
 char *filename;
@@ -224,6 +225,35 @@ derive_tags_from_maildir_flags (notmuch_message_t *message,
 }
 }
 
+static char*
+_get_folder_base_name(const char *path)
+{
+gchar *full_folder_name = NULL;
+gchar *folder_base_name = NULL;
+
+/* Find name of folder containing the email. */
+full_folder_name = g_strdup(path);
+while (1) {
+	folder_base_name = g_path_get_basename(full_folder_name);
+
+	if (strcmp(folder_base_name, cur) == 0
+	|| strcmp(folder_base_name, new) == 0) {
+	gchar *parent_name = g_path_get_dirname(full_folder_name);
+	g_free(full_folder_name);
+	full_folder_name = parent_name;
+	} else
+	break;
+}
+
+g_free(full_folder_name);
+
+if (strcmp(folder_base_name, .) == 0) {
+	g_free(folder_base_name);
+	folder_base_name = NULL;
+}
+return folder_base_name;
+}
+
 /* Examine 'path' recursively as follows:
  *
  *   o Ask the filesystem for the mtime of 'path' (fs_mtime)
@@ -277,6 +307,7 @@ add_files_recursive (notmuch_database_t *notmuch,
 notmuch_filenames_t *db_subdirs = NULL;
 struct stat st

[notmuch] [Sebastian Spaeth] Pull requests

[micah anderson]

On Mon, 01 Mar 2010 15:57:00 +0100, "Sebastian Spaeth"  wrote:

> From git repository git://github.com/spaetz/notmuch-all-feature.git I
> would like to advocate the following branches for quick pulling. Each
> contains 1 or 2 patches. They have all been based on todays
> cworth/master, so it should be really painless.

Thanks for pulling these all together! All the ones that you propose I
also use and would really like these to be merged as well.

The only other patch that I find absolutely crucial, that you do not
include, is the 'Preserve folder information when indexing' patch which,
although not perfect, does significantly change my life. 

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

Re: [notmuch] [Sebastian Spaeth] Pull requests

[micah anderson]

On Mon, 01 Mar 2010 15:57:00 +0100, Sebastian Spaeth sebast...@sspaeth.de 
wrote:

 From git repository git://github.com/spaetz/notmuch-all-feature.git I
 would like to advocate the following branches for quick pulling. Each
 contains 1 or 2 patches. They have all been based on todays
 cworth/master, so it should be really painless.

Thanks for pulling these all together! All the ones that you propose I
also use and would really like these to be merged as well.

The only other patch that I find absolutely crucial, that you do not
include, is the 'Preserve folder information when indexing' patch which,
although not perfect, does significantly change my life. 

micah


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

[notmuch] Initial tagging

[micah anderson]

Hey james,

i really like your notmuch-retry bits, I've taken that shell script and
integrated it into my tagging script, thanks! I'm curious if you are
going to update your patch for notmuch.el ("Calls to notmuch get queued
and executed asynchronously") to use this, or if you are going to have
those two continue to be separate ways of retrying?

On Thu, 25 Feb 2010 16:25:16 -0500, James Vasile  
wrote:

> The tagging script uses the inbox tag to identify new mail, tags it
> according to criteria, then removes the inbox tag from anything it found
> a match for.  Uncategorized mail keeps the inbox tag so I can inspect it
> later and make rules for it (or tag it manually).

Why do you tag new mail with tags, rather than construct folder searches
to create views? 

For example, rather than adding more and more data to the database every
time your script runs and does something like the following:

tag_new "+list +notmuch" "to:notmuchmail.org or notmuch"

Why don't you instead create a folder in your .emacs like this:

(setq notmuch-folders '(("inbox" . "tag:inbox")
("unread" . "tag:inbox AND tag:unread")
("notmuch" . "to:notmuchmail.org")))

That way, if you want to read the notmuch mailing list, you would simply
open that folder, which would present you with the results of that
search. 

You could do different things with the tag:unread and tag:inbox flags,
depending on what you wanted to accomplish. Namely, you may wish to only
have a view of all the unread notmuch mailing list messages, in which
case you would make that query "tag:unread AND to:notmuchmail.org".

I'm just curious about the rationale for doing it one way, over the
other. 

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

[notmuch] Initial tagging

[micah anderson]

On Thu, 25 Feb 2010 16:25:16 -0500, James Vasile  
wrote:

> I'm curious as to what people are doing in this regard.

I am pretty good at evangelizing notmuch and converted another
person[0]... in doing so I realized I had to walk through a few issues
to get them started. 

The initial documentation for notmuch is really great, but the other
magical bits are missing, like "holy cow all my email is in my inbox
now!"; "how do I deal with folders?"; "do i run notmuch new every
time?"; "do you auto-tag things?"; "how do you deal with attachments?";
"how do you read encrypted email"? etc. etc. all of these getting
started with notmuch things... including the script that James just
posted, the getmail tagging stuff that was posted a little while back,
etc. 

This stuff should go up on the wiki! There is a "Tips and Tricks for
using notmuch with Emacs" section, but more general things like James'
script and other people's scripts really should be put up there so
people who are new can figure out how to get started faster.

So this is just a call out to try and encourage people to put these
useful things that they have sent out to the list up onto the wiki! Most
people don't read all the past archives of a list when they first join,
but do check out the website for info on how to get going. I'm not
saying don't send things to the list either, just don't let the list be
the sink where these great tips go to die.

micah


0. indirectly I believe am also responsible, through 3rd party
evangelizing, for James entering the scene as well, and I'm happy about
that because I have been quite pleased with his enhancements, thanks
james!. now I just need to buy him a drink and talk him into fixing the
openpgp bits ;)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: [notmuch] Initial tagging

[micah anderson]

On Thu, 25 Feb 2010 16:25:16 -0500, James Vasile ja...@hackervisions.org 
wrote:

 I'm curious as to what people are doing in this regard.

I am pretty good at evangelizing notmuch and converted another
person[0]... in doing so I realized I had to walk through a few issues
to get them started. 

The initial documentation for notmuch is really great, but the other
magical bits are missing, like holy cow all my email is in my inbox
now!; how do I deal with folders?; do i run notmuch new every
time?; do you auto-tag things?; how do you deal with attachments?;
how do you read encrypted email? etc. etc. all of these getting
started with notmuch things... including the script that James just
posted, the getmail tagging stuff that was posted a little while back,
etc. 

This stuff should go up on the wiki! There is a Tips and Tricks for
using notmuch with Emacs section, but more general things like James'
script and other people's scripts really should be put up there so
people who are new can figure out how to get started faster.

So this is just a call out to try and encourage people to put these
useful things that they have sent out to the list up onto the wiki! Most
people don't read all the past archives of a list when they first join,
but do check out the website for info on how to get going. I'm not
saying don't send things to the list either, just don't let the list be
the sink where these great tips go to die.

micah


0. indirectly I believe am also responsible, through 3rd party
evangelizing, for James entering the scene as well, and I'm happy about
that because I have been quite pleased with his enhancements, thanks
james!. now I just need to buy him a drink and talk him into fixing the
openpgp bits ;)


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

[notmuch] notmuch.el: Prefix arg inverts the sort order of notmuch-search.

[micah anderson]

On Thu, 11 Feb 2010 15:20:54 +0100 (CET), racin at free.fr wrote:

> Using a prefix arg to invert search order would conflict with my patch
> http://notmuchmail.org/pipermail/notmuch/2009/000914.html in which the
> prefix arg is used to show deleted messages. I don't known which
> behaviour for prefix patch would be best.

I always understood a prefix arg to invert the original (or provide a
numeric repetition), but I do not have a wide sample to tell if this is
how most elisp implements it. 

> Though we can also add "toggle keys" that toggle search order, or
> toggle display of deleted messages, which would solve the problem.

There is the 'o' key now which toggles the search order, isn't there? 

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

Re: [notmuch] notmuch.el: Prefix arg inverts the sort order of notmuch-search.

[micah anderson]

On Thu, 11 Feb 2010 15:20:54 +0100 (CET), ra...@free.fr wrote:

 Using a prefix arg to invert search order would conflict with my patch
 http://notmuchmail.org/pipermail/notmuch/2009/000914.html in which the
 prefix arg is used to show deleted messages. I don't known which
 behaviour for prefix patch would be best.

I always understood a prefix arg to invert the original (or provide a
numeric repetition), but I do not have a wide sample to tell if this is
how most elisp implements it. 

 Though we can also add toggle keys that toggle search order, or
 toggle display of deleted messages, which would solve the problem.

There is the 'o' key now which toggles the search order, isn't there? 

m


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

[notmuch] emacs: On getting support for inline images

[micah anderson]

On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth  wrote:
> I investigated a bit and discovered that the images are being rendered
> within emacs and inside of a temporary buffer that is being used by the
> function invoked by 'v'. Before this function returns, the temporary
> buffer including the nicely inline-rendered image is being killed. (And
> I suspect the exact same thing is happening with encrypted messages
> where hitting 'v' gets emacs to prompt for the passphrase, but then
> nothing is displayed to the user.)
> 
> I was able to get images working by customizing the
> mm-inline-media-tests variable. I removed the image/png clause from the
> value, and now when I hit 'v' I get a nice, external image viewer as
> configured in /etc/mailcap, etc.
> 
> Here are some ideas for possible (and independent) fixes:
> 
> 1. With the current setup, we know we are using a temporary buffer that
>the user won't see, so notmuch could temporarily set
>mm-inline-media-tests to nil forcing everything to use external
>viewers when the user presses 'v'.

This would leave encrypted messages in a weird spot. What external
viewer would you want to be launched when you press 'v' on an encrypted
message? I'd like it to be emacs myself, and even better I want it to be
in notmuch/mml-mode so I can reply to it and get quoting. Although this
option seems like the easiest solution, it avoids the problem, and
unfortunately not very well. Emacs can display images and PDFs fine too,
it just can't do openoffice documents, yet ;)

> 2. The original presentation of Mime parts could examine
>mm-inline-media-tests and directly render anything possible within
>the original presentation of the message. This would allow images to
>be viewed directly without requiring the user to press 'v'. And the
>user could configure this existing variable to control what content
>is displayed inline.

This seems like the right way to handle things in the emacs mode.

> 3. We could move away from these various mm- functions for displaying
>MIME parts and simply add functionality to the notmuch command line
>for extracting individual MIME parts from messages, (which is
>something that a non-emacs client will likely want anyway). Then we
>can use the lower-level functions to display things directly. (For
>example, displaying an image looks as simple as calling the
>create-image and put-image functions).

I would think that the mm functions are probably pretty battle-tested
and have been in a lot of very careful honing over the years. They
probably do the right thing, and do it well because a lot of work has
gone into getting them right. I'm sure there is a big here and there,
but still it seems like it would be a shame not to use something that
has a pretty full feature-set. 

On the other-hand, I see your point about non-emacs clients, and the
command-line having the ability to parse our MIME parts. Perhaps there
is room for both to play?

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

Re: [notmuch] emacs: On getting support for inline images

[micah anderson]

On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth cwo...@cworth.org wrote:
 I investigated a bit and discovered that the images are being rendered
 within emacs and inside of a temporary buffer that is being used by the
 function invoked by 'v'. Before this function returns, the temporary
 buffer including the nicely inline-rendered image is being killed. (And
 I suspect the exact same thing is happening with encrypted messages
 where hitting 'v' gets emacs to prompt for the passphrase, but then
 nothing is displayed to the user.)
 
 I was able to get images working by customizing the
 mm-inline-media-tests variable. I removed the image/png clause from the
 value, and now when I hit 'v' I get a nice, external image viewer as
 configured in /etc/mailcap, etc.
 
 Here are some ideas for possible (and independent) fixes:
 
 1. With the current setup, we know we are using a temporary buffer that
the user won't see, so notmuch could temporarily set
mm-inline-media-tests to nil forcing everything to use external
viewers when the user presses 'v'.

This would leave encrypted messages in a weird spot. What external
viewer would you want to be launched when you press 'v' on an encrypted
message? I'd like it to be emacs myself, and even better I want it to be
in notmuch/mml-mode so I can reply to it and get quoting. Although this
option seems like the easiest solution, it avoids the problem, and
unfortunately not very well. Emacs can display images and PDFs fine too,
it just can't do openoffice documents, yet ;)

 2. The original presentation of Mime parts could examine
mm-inline-media-tests and directly render anything possible within
the original presentation of the message. This would allow images to
be viewed directly without requiring the user to press 'v'. And the
user could configure this existing variable to control what content
is displayed inline.

This seems like the right way to handle things in the emacs mode.

 3. We could move away from these various mm- functions for displaying
MIME parts and simply add functionality to the notmuch command line
for extracting individual MIME parts from messages, (which is
something that a non-emacs client will likely want anyway). Then we
can use the lower-level functions to display things directly. (For
example, displaying an image looks as simple as calling the
create-image and put-image functions).

I would think that the mm functions are probably pretty battle-tested
and have been in a lot of very careful honing over the years. They
probably do the right thing, and do it well because a lot of work has
gone into getting them right. I'm sure there is a big here and there,
but still it seems like it would be a shame not to use something that
has a pretty full feature-set. 

On the other-hand, I see your point about non-emacs clients, and the
command-line having the ability to parse our MIME parts. Perhaps there
is room for both to play?

micah


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

[notmuch] loss of duplicate messages

[micah anderson]

On Fri, 05 Feb 2010 14:47:03 -0500, Jameson Rollins  wrote:
> On Fri, 05 Feb 2010 14:39:22 -0500, micah anderson  
> wrote:
> > Welcome to how gmail does it.
> 
> Why welcome me to "how gmail does it"?!  I never wanted to go there!

Because the perception of the internet by the third larges mail provider
on the internet, with over 146 million users[0] is not a trivial number
that can be ignored.

Maybe I should have said, "welcome to the place where you do not wish to
tread, the place where 1/3rd of the people using the internet have their
perceptions shaped. be careful, there is a lot of stuff here you do not
want to step in!"

micah


0. Arrington, Michael (2009-07-09). "Bing Comes to Hotmail". Techcrunch. 
http://www.techcrunch.com/2009/07/09/bing-comes-to-hotmail/. Retrieved 
2009-07-11. "Hotmail is still by far the largest web mail provider on the 
Internet, with 343 million monthly users according to Comscore. Second and 
third are Yahoo (285 million) and Gmail (146 million)." 
-- 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/20100205/7af9e309/attachment.pgp>

[notmuch] loss of duplicate messages

[micah anderson]

On Fri, 05 Feb 2010 12:49:21 -0500, Jameson Graef Rollins  wrote: 
> A policy of only returning one is going to be problematic for folks who
> want or expect to see the other.  And in fact think I want to see both.
> I have both, and I've asked notmuch to index both, so why shouldn't it
> return both in a search?

Welcome to how gmail does it. When they first hit the scene, as an
operator of a large mailing list service, I was *constantly* being
bugged with support issues from people who were expecting this very
behavior, "I sent a message to the list, but I never got it, did it get
posted to the list?!". Soon I found out that gmail did exactly what
you are reporting notmuch as doing.

The frightening thing is that over the last few years of gmail's
existence, those complaints and support issues have totally gone
away. Does that mean that gmail has trained people to no longer expect
this behavior?

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

[notmuch] Backport of Xapian term update optimisation

[micah anderson]

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

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

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

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

Re: [notmuch] Backport of Xapian term update optimisation

[micah anderson]

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

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

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

micah


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

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

[micah anderson]

On Wed, 03 Feb 2010 18:37:57 -0500, Jameson Rollins  wrote:
> On Thu, 4 Feb 2010 09:41:41 +1300, martin f krafft  
> wrote:
> > also sprach David Bremner  [2010.02.04.0924 +1300]:
> > > > PS: speaking of prefixes, how about remving the subject prefix of
> > > > this list in general? ;)
> > > 
> > > I used to agree, but in notmuch, I actually find it convenient to have
> > > threads marked by mailing list. Perhaps this will change if/when my
> > > email setup or the notmuch emacs ui get better...
> > 
> > sed -e 's,^Subject:,& [notmuch],'
> 
> I think I might agree with Martin.  The subject prefix doesn't really
> seem necessary with notmuch, considering that for the following two
> searches:
> 
> notmuch search to:notmuch at notmuchmail.org
> notmuch search subject:[notmuch]

That is because xapian doesn't doesn't ount [] as words so doesn't index
them[0].

micah


0. according to kanru on IRC
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[notmuch] New wiki instance on the notmuchmail.org website

[micah anderson]

On Tue, 02 Feb 2010 23:44:56 -0800, Carl Worth  wrote:
> So Keith tells me he's entirely unimpressed with my website-design
> skills as evidenced by http://notmuchmail.org .
> 
> In an effort to fix this, I've switched from the single, static HTML
> page that was there previously, to now using ikiwiki to generate a
> remarkably similar-looking, single, static web page.

Your design skills are remarkable at reproducing the same website!

> The benefit is that there's now a git repository for the website, (with
> source in markdown format), and more importantly, the git repository
> will accept a "git push" without any authentication necessary.

This is really cool, thanks for doing this and making it open like this!

I don't know ikiwiki that well, but I imagine there is a way (probably
via a git post-commit hook) to email changes that have been pushed. This
might be a good way to keep up with what people are changing on the
site, although sending it to this list might be too much, perhaps
another mailing list for those gluttons who would like to see this?

micah

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

[notmuch] [PATCHv2] Preserve folder information when indexing

[micah anderson]

On Tue, 02 Feb 2010 13:22:29 -0500, Jameson Rollins  wrote:
> I'm starting to think that maybe the folder: field is not the right way
> to do this, though.  What if a message moves?  

The easiest way to answer this question is to try it. I did that, and
things didn't work as expected. I expected that once the message was
moved to a different folder, and 'notmuch new' was run, then the folder
search result would move with the message move. 

I tried to move a message from folder 'thinkpad' to folder 'Junk':

1. First I did a search that included the thinkpad folder, with a string
I know is in an email:

$ notmuch search folder:thinkpad 05K9519
thread:4ba02e2c665b09fb74dc6f1b6ea3aac2   2004-02-25 [1/1] J H. Maut; RE: 
[Thinkpad] thinkpad 600e LCD quesiton (thinkpad unread)

2. then I moved that email to my Junk folder and ran notmuch new:

$ mv 
INBOX.thinkpad/new1147465172.M760586P11592V0301I00141D45_7229.um\,S\=2421\:2\,S
 INBOX.Junk/new
$ notmuch new
Processed 1 file in almost no time.
No new mail. Detected 1 file rename.

3. then I tried to repeat the search I did in #1, searching for the
folder thinkpad and the string, and it still returns the result (this is
not expected! I would expect no result returned):

$ notmuch search folder:thinkpad 05K9519
thread:4ba02e2c665b09fb74dc6f1b6ea3aac2   2004-02-25 [1/1] J H. Maut; RE: 
[Thinkpad] thinkpad 600e LCD quesiton (thinkpad unread)

4. If i try and search for the same message in the Junk folder, I get no
results:

$ notmuch search folder:Junk 05K9519
$ 

5. If I do a show on the message, I see that notmuch knows that the
file is actually in the Junk folder:

$ notmuch show thread:4ba02e2c665b09fb74dc6f1b6ea3aac2

message{ id:BKEJKEHBAJJAFLAGIHJCGCAA.J.H.Maut at somewhere.net depth:0 
match:1 
filename:/home/micah/Maildir/Personal/INBOX.Junk/new/1147465172.M760586P11592V0301I00141D45_7229.um,S=2421:2,S


> Only new mails are having this field modified, so if messages are
> moved that field is not modified, and since it's being added as part
> of the message (like "subject:") it's not modifiable.  

Exactly the problem.

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

[notmuch] [PATCH 2/2] Preserve folder information when indexing

[micah anderson]

On Thu, 28 Jan 2010 16:25:17 +0100, Michal Sojka  wrote:
> This patch was originally sent by Andreas Kl?ckner. This is a slightly
> reworked version (only coding style changes) which was manually rebased
> to the current HEAD.

Just a quick note about this patch: I received an offline email back

[notmuch] [patch] store folder information

[micah anderson]

Hi Andreas,

I'm just writing because of the patch you sent to the notmuch list on
December 15th. It seems like many people are wanting this functionality,
I know I am myself and Carl has also indicated the same. However, there
were a couple of minor suggestions for improvements for your patch that
have not seen a reply from you yet. I'm particularly eager to see this
get accepted upstream, and it sounds like the changes necessary to do so
are relatively minor.

I'm wondering what your plans are for addressing these issues? I've come
to depend on this functionality, and would love to see it incorporated
upstream! 

Specifically these were:

1. Unrelated whitespace:

On December 16th,2009 Ruben Pollan  wrote:

> [meskio at blackspot:src/notmuch.orig]$ git apply 
> ~/0001-Preseve-folder-information-when-indexing.patch
> /home/meskio/0001-Preseve-folder-information-when-indexing.patch:136: 
> trailing whitespace.
>status notmuch_database_add_message (notmuch, next,
> /home/meskio/0001-Preseve-folder-information-when-indexing.patch:137: 
> trailing whitespace.
>   folder_base_name,
> warning: 2 lines add whitespace errors.
>
> It's just whitespaces at the end of the lines.

2. An unrelated hunk creeping in:

On Tue, 15 Dec 2009 13:22:19 -0800, Carl Worth  wrote:
> On Mon, 14 Dec 2009 14:21:50 -0500, Andreas Kl=C3=B6ckner  wrote:
> >
> > @@ -116,6 +116,8 @@ skip_re_in_subject (const char *subject)
> > s++;
> > if (strncasecmp (s, "re:", 3) =3D=3D 0)
> > s +=3D 3;
> > +else if (strncasecmp (s, "aw:", 3) =3D=3D 0)
> > +   s +=3D 3;
> > else
> > break;
> >  }
>=20
> This hunk looks unrelated to the rest. Could you submit that separately,
> please?


3. Redundant trailing directory name traversal:

> > +gchar *full_folder_name =3D NULL;
> > +gchar *folder_base_name =3D NULL;
> > +
> > +/* Find name of "folder" containing the email. */
> > +full_folder_name =3D g_strdup(path);
> > +while (1)
> > +{
> > +folder_base_name =3D g_path_get_basename(full_folder_name);
>
> The trailing directory name is available already during the
> traversal. So you don't need to search it back out again. See the patch
> in the following message:
>
>   id:87fx8bygi7.fsf at linux.vnet.ibm.com
>
> which simply passes the trailing directory name along, (but skipping a
> name of "cur" or "new" while traversing).

4. supporting hierarchical folders (perhaps this is a later improvement
that does not need to be added before the original patch is accepted?):

> Beyond that, though, I imagine some people have hierarchical folders as
> well, so it probably makes sense to store them as well.
>
> To do that, it's probably just a matter of calling gen_terms on the
> complete filename. I haven't tested, but doing that should allow
> Xapian's phrase searching to do the right thing for something like:
>
>   filename:portion/of/the/path/name

5. Probably the patch needs to be rebased off of master at this point.

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

[notmuch] Git feature branch

[micah anderson]

On Mon, 25 Jan 2010 16:46:43 -0800, sebastian at sspaeth.de wrote:
> > I think it would make sense to move the mainline to git.debian.org
> > for now, or another place where everyone can easily get an account.
> > As alternatives I propose repo.or.cz. I'd prefer to stay away from
> > commercial services like Github.

I too prefer to stay away from commercial,non-free services like GitHub.
Gitorious (http://www.gitorious.org/) is a great service, similar to
Github, but with added freedom.

Currently the git repository is at git://notmuchmail.org/git/notmuch
which seems like a fine location for it, but perhaps I missed the
motivation for switching to a centralized repository with the added
overhead of giving people access to commit?

Couldn't all of this be done without moving the existing git repository
(don't forget that transition is a cost)? Those who wish to put together
these proposed branches go ahead and do so, publishing those wherever
they like (git.debian.org, gitorious, their own hosted git repositories,
or even github) and then Carl can just add those as remotes as he sees
fit.

> > What patch tracking workflow should we adopt? Keep sending patches
> > to the mailing list and have a few people who integrate them into
> > master or pu (or even maint/next), as appropriate? Use the Debian
> > bug tracker? Use Sebastian's Roundup instance? Set up a patch queue
> > manager on notmuchmail.org? Use patchwork [1]?

Personally, I've found mailing lists that have patches sent to them
tends to totally kill the list for anything else. It seems a bit weird
to use Debian's bug tracker for a non-Debian native program (but using
it for the Debian package of notmuch does make sense). I am not so
familiar with Roundup, patch queue trackers or patchwork to have
anything to say about those.

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

Re: [notmuch] [patch] store folder information

[micah anderson]

Hi Andreas,

I'm just writing because of the patch you sent to the notmuch list on
December 15th. It seems like many people are wanting this functionality,
I know I am myself and Carl has also indicated the same. However, there
were a couple of minor suggestions for improvements for your patch that
have not seen a reply from you yet. I'm particularly eager to see this
get accepted upstream, and it sounds like the changes necessary to do so
are relatively minor.

I'm wondering what your plans are for addressing these issues? I've come
to depend on this functionality, and would love to see it incorporated
upstream! 

Specifically these were:

1. Unrelated whitespace:

On December 16th,2009 Ruben Pollan mes...@sindominio.net wrote:

 [mes...@blackspot:src/notmuch.orig]$ git apply 
 ~/0001-Preseve-folder-information-when-indexing.patch
 /home/meskio/0001-Preseve-folder-information-when-indexing.patch:136: 
 trailing whitespace.
status notmuch_database_add_message (notmuch, next,
 /home/meskio/0001-Preseve-folder-information-when-indexing.patch:137: 
 trailing whitespace.
   folder_base_name,
 warning: 2 lines add whitespace errors.

 It's just whitespaces at the end of the lines.

2. An unrelated hunk creeping in:

On Tue, 15 Dec 2009 13:22:19 -0800, Carl Worth cwo...@cworth.org wrote:
 On Mon, 14 Dec 2009 14:21:50 -0500, Andreas Kl=C3=B6ckner li...@informa.=
tiker.net wrote:
 
  @@ -116,6 +116,8 @@ skip_re_in_subject (const char *subject)
  s++;
  if (strncasecmp (s, re:, 3) =3D=3D 0)
  s +=3D 3;
  +else if (strncasecmp (s, aw:, 3) =3D=3D 0)
  +   s +=3D 3;
  else
  break;
   }
=20
 This hunk looks unrelated to the rest. Could you submit that separately,
 please?


3. Redundant trailing directory name traversal:

  +gchar *full_folder_name =3D NULL;
  +gchar *folder_base_name =3D NULL;
  +
  +/* Find name of folder containing the email. */
  +full_folder_name =3D g_strdup(path);
  +while (1)
  +{
  +folder_base_name =3D g_path_get_basename(full_folder_name);

 The trailing directory name is available already during the
 traversal. So you don't need to search it back out again. See the patch
 in the following message:

   id:87fx8bygi7@linux.vnet.ibm.com

 which simply passes the trailing directory name along, (but skipping a
 name of cur or new while traversing).

4. supporting hierarchical folders (perhaps this is a later improvement
that does not need to be added before the original patch is accepted?):

 Beyond that, though, I imagine some people have hierarchical folders as
 well, so it probably makes sense to store them as well.

 To do that, it's probably just a matter of calling gen_terms on the
 complete filename. I haven't tested, but doing that should allow
 Xapian's phrase searching to do the right thing for something like:

   filename:portion/of/the/path/name

5. Probably the patch needs to be rebased off of master at this point.

Micah


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

[notmuch] Git feature branch

[micah anderson]

On Wed, 20 Jan 2010 15:00:46 +0100, "Sebastian Spaeth"  wrote:
> As I do like some of the additional patches, I am shoving some of them
> into my "all feature" branch. I make that one available in case you
> want to pull from it. It currently carries:
> 
> Jameson Rollins: Simplify "unread" tag handling in emacs UI.
> David Bremner: notmuch.el: Refactor citation markup. Variables for minimum 
> size, button text.
> Dirk-Jan C. Binnema: notmuch-new.c: refactor and improve dirs-to-ignore a bit
> Sebastian Spaeth: add notmuch-show-delete keybinding 'd'

Cool! It would be useful if you provided thread-id's for each of these
so we could look them up and read more about them.

micah

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

[notmuch] [PATCH] Use libgcrypt for hashing.

[micah anderson]

On Fri, 27 Nov 2009 22:22:01 -0800, Carl Worth  wrote:
> On Fri, 27 Nov 2009 21:28:03 -0600, "Jeffrey C. Ollie"  
> wrote:
> > Instead of including a private implementation of the SHA1 hash, use
> > libgcrypt.  This means less code of our own to maintain and it will be
> > easier to switch to a different hash function like SHA256.
> 
> I don't believe we have a significant code-maintenance burden with
> libsha1.c. And as for different hash functions, the only use of sha-1 in
> notmuch is as a fallback in the case of a message not including a
> Message-ID header.
> 
> So I don't see it as important at all to try to remove this code.

Its good that this is not a burden to maintain for the notmuch project,
even better that Mikhail, the libsha1 maintainer, is currently active in
this project and has volunteered to maintain the in-tree copy. 

However, the problem that has been raised is about the code-maintenance
burden that distributions face. In fact, this is not an unique problem
to notmuch, if it was it wouldn't be such a big deal. The reality is
that the more projects which cargo-cult around 'convenience copies' of
code, the more of a burden is placed on the distributors.

In some ways, the notmuch project and the role of distributors are at
cross-purposes on this issue, each side has an argument that makes sense

[notmuch] indexing encrypted messages (was: OpenPGP support)

[micah anderson]

On Fri, 8 Jan 2010 10:21:21 +0100, Ruben Pollan  
wrote:
> On 15:56, Fri 08 Jan 10, martin f krafft wrote:
> > How about indexing GPG-encrypted messages?
> 
> I think that would be security hole. You should not store the
> encrypted messages on a decrypted database. A solution whould be to
> encrypt as well the xapian DB, but I think is too complex for the use.

Would you consider it a security hole if you stored your database on
encrypted media (such as on-disk block encryption)?

I know that sup does this, when it ran over my mail store, it would
trigger my gpg agent so that it could decrypt the encrypted
messages. This was annoying because this happened every time it ran,
which meant that unless I had used gpg recently, my agent would pop up
and ask me for my passphrase, which was often.

The way Mutt provides this functionality is by decrypting only when you
perform the search itself.

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

[notmuch] update on delete/rename support

[micah anderson]

On Sat, 26 Dec 2009 12:12:09 -0400, David Bremner  wrote:

>You may have to wrap your "notmuch new" call in a "notmuch save",
>"notmuch restore" pair if you discover things coming back to your inbox.

do you mean "notmuch dump" here instead of "notmuch save"?

> The whole dump-maildirsync-new-restore cycle takes about 30s for me
> check mail, a bit longer if there is actually new mail.

I'm trying to unpack what you are saying here. Are you saying that if
you are getting things coming back into your inbox, and you have not
applied your "lazy restore" patch, then you would need a script to check
your email which does:

notmuch dump > /tmp/notmuch.dump
offlineimap 
notmuch new
notmuch restore < /tmp/notmuch.dump

micah

[notmuch] Quick thoughts on a notmuch daemon

[micah anderson]

Excerpts from Marten Veldthuis's message of Mon Dec 07 17:55:24 -0500 2009:
> On Mon, 07 Dec 2009 15:02:03 -0400, David Bremner  
> wrote:
> > 
> > On Thu, 03 Dec 2009 14:27:05 -0800, Carl Worth  wrote:
> > It might be a bit blue sky, but if this daemon could (optionally) talk
> > IMAP and translate tags into folders on the fly, this would be very
> > useful for people who need imap access to their mail as well as from an
> > custom notmuch client.
> 
> For me, my IMAP needs are pretty much limited to my iPhone. I'm making
> do for now, but to make notmuch viable in the long term, what I'd need
> is:
> 
>  * notmuch shouldn't choke on mails I had in notmuch's database, and
>then marked read or deleted on my iPhone (which renames them in the
>maildir). This is coming with the moving/deleting patches.
>  * notmuch should sync back read/unread state to maildir
>  * notmuch should move read stuff out of my inbox. It would be
>acceptable if it moved everything into a designated archive folder
>unless it had the 'inbox' tag assigned, in which case it moved it
>there. Note that we have the moving/deleting patches, then this could
>even be done as a script and some searches.
> 
> With this, my inbox would be usable from my iPhone.

I dont have an iPhone, but this would be a *killer* feature for me, and
I suspect for others as well. 

I have two fundamental problems with label-state clients (sup, notmuch)
that I am still trying to come to terms with, this bluesky feature would
change that radically.

The first issue is that I do not have unlimited IMAP storage space on
the server, in fact I have a quota. I know, lots of people have
effectively unlimited space,and others POP/fetchmail things so its not
stored on the server...but lots of us still do have upper limits that we
have to deal with and many of us do use IMAP, for good reasons. With
label-state clients (sup, notmuch) you have to accept the fact that your
mail is going to grow on the IMAP server indefinitely. This is not a
good thing for those of us with quotas, but it is also a bad thing for
some IMAP servers who choke to death on very large IMAP stores (or
consume an awful lot of memory dealing with them). Or you have to setup
kludgy archive operations to periodically deal with the disk space
issue.

The second mind-bending problem is that sometimes I actually do have to
use mutt, sometimes webmail (for various reasons, but one important one
in the early stages of a new email client is that notmuch just doesn't
have support for certain operations such as inline/pgp-mime handling of
emails, which means I need to open those emails in other clients that do
support that). Other people likely are going to need to use things like
iphones or blackberries. Indeed, using other clients is not an
unreasonable thing for people to do. However, switching between notmuch
and these clients is. Because the message state is stored in a DB which
is only useful for notmuch, its a dreadful nightmare to do anything
outside of the notmuch world.

Most importantly, having all of your email state in a notmuch database
format means that it can only be parsed by those tools, and is no longer
in a standard format. I think it is great that 'notmuch restore' can
deal with the sup database format, which may signal the dawn of a new
label-state standardbut still the problem is the glue to the
underlying maildir structure which provides a lot of useful information
contained in reasonably well-defined ways is totally thrown out the
window. 

I've switched mail clients enough over the past few years to know that
switching itself is a major pain. I've settled on Maildir as my storage
method of choice and in a way it is a 'client'. I can serve it via IMAP
if I need, I can read it with different mail clients and maintain state
across those mail clients, there are tools to manipulate and convert
maildirs that have matured over the years. If I switch to an
'all-in-one' label-state mail client, like notmuch, I want to be sure
that in 2 years from now if I happen to decide to change to something
else (I'm hoping this wont EVER happen because notmuch is very
promising, but I need to be honest based on past experiences here), then
I'm going to want to make sure that all of my mail is marked as read,
deleted mail is deleted and even though I was using labels for
organizational purposes in notmuch, things are still organized in some
way appropriate to folders on the filesystem.

The way it is now, if I switch to notmuch and then try to switch back,
my life is a total mess because all of the state is contained within the
notmuch database, that is frightening for the long-term, but it also
makes me very worried about simple corruption of that data store. If I
lose that state, I'm totally screwed. At least in a maildir scenario, if
I got corruption in one place it might cause me to lose one email, but
if I get corruption in my notmuch database, I had better have a recent

Re: [notmuch] Quick thoughts on a notmuch daemon

[micah anderson]

Excerpts from Marten Veldthuis's message of Mon Dec 07 17:55:24 -0500 2009:
 On Mon, 07 Dec 2009 15:02:03 -0400, David Bremner da...@tethera.net wrote:
  
  On Thu, 03 Dec 2009 14:27:05 -0800, Carl Worth cwo...@cworth.org wrote:
  It might be a bit blue sky, but if this daemon could (optionally) talk
  IMAP and translate tags into folders on the fly, this would be very
  useful for people who need imap access to their mail as well as from an
  custom notmuch client.
 
 For me, my IMAP needs are pretty much limited to my iPhone. I'm making
 do for now, but to make notmuch viable in the long term, what I'd need
 is:
 
  * notmuch shouldn't choke on mails I had in notmuch's database, and
then marked read or deleted on my iPhone (which renames them in the
maildir). This is coming with the moving/deleting patches.
  * notmuch should sync back read/unread state to maildir
  * notmuch should move read stuff out of my inbox. It would be
acceptable if it moved everything into a designated archive folder
unless it had the 'inbox' tag assigned, in which case it moved it
there. Note that we have the moving/deleting patches, then this could
even be done as a script and some searches.
 
 With this, my inbox would be usable from my iPhone.

I dont have an iPhone, but this would be a *killer* feature for me, and
I suspect for others as well. 

I have two fundamental problems with label-state clients (sup, notmuch)
that I am still trying to come to terms with, this bluesky feature would
change that radically.

The first issue is that I do not have unlimited IMAP storage space on
the server, in fact I have a quota. I know, lots of people have
effectively unlimited space,and others POP/fetchmail things so its not
stored on the server...but lots of us still do have upper limits that we
have to deal with and many of us do use IMAP, for good reasons. With
label-state clients (sup, notmuch) you have to accept the fact that your
mail is going to grow on the IMAP server indefinitely. This is not a
good thing for those of us with quotas, but it is also a bad thing for
some IMAP servers who choke to death on very large IMAP stores (or
consume an awful lot of memory dealing with them). Or you have to setup
kludgy archive operations to periodically deal with the disk space
issue.

The second mind-bending problem is that sometimes I actually do have to
use mutt, sometimes webmail (for various reasons, but one important one
in the early stages of a new email client is that notmuch just doesn't
have support for certain operations such as inline/pgp-mime handling of
emails, which means I need to open those emails in other clients that do
support that). Other people likely are going to need to use things like
iphones or blackberries. Indeed, using other clients is not an
unreasonable thing for people to do. However, switching between notmuch
and these clients is. Because the message state is stored in a DB which
is only useful for notmuch, its a dreadful nightmare to do anything
outside of the notmuch world.

Most importantly, having all of your email state in a notmuch database
format means that it can only be parsed by those tools, and is no longer
in a standard format. I think it is great that 'notmuch restore' can
deal with the sup database format, which may signal the dawn of a new
label-state standardbut still the problem is the glue to the
underlying maildir structure which provides a lot of useful information
contained in reasonably well-defined ways is totally thrown out the
window. 

I've switched mail clients enough over the past few years to know that
switching itself is a major pain. I've settled on Maildir as my storage
method of choice and in a way it is a 'client'. I can serve it via IMAP
if I need, I can read it with different mail clients and maintain state
across those mail clients, there are tools to manipulate and convert
maildirs that have matured over the years. If I switch to an
'all-in-one' label-state mail client, like notmuch, I want to be sure
that in 2 years from now if I happen to decide to change to something
else (I'm hoping this wont EVER happen because notmuch is very
promising, but I need to be honest based on past experiences here), then
I'm going to want to make sure that all of my mail is marked as read,
deleted mail is deleted and even though I was using labels for
organizational purposes in notmuch, things are still organized in some
way appropriate to folders on the filesystem.

The way it is now, if I switch to notmuch and then try to switch back,
my life is a total mess because all of the state is contained within the
notmuch database, that is frightening for the long-term, but it also
makes me very worried about simple corruption of that data store. If I
lose that state, I'm totally screwed. At least in a maildir scenario, if
I got corruption in one place it might cause me to lose one email, but
if I get corruption in my notmuch database, I had better have a recent