[PATCH] new: read db_files and db_subdirs if mtime changed
The db_files and db_subdirs are unnecessary for unchanged directories.
maildir with 1 e-mails:
old version:
$ time ./notmuch new
No new mail.
real0m0.053s
user0m0.028s
sys 0m0.026s
new version:
$ time ./notmuch new
No new mail.
real0m0.032s
user0m0.009s
sys 0m0.023s
Signed-off-by: Karel Zak
---
notmuch-new.c | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/notmuch-new.c b/notmuch-new.c
index 941f9d6..31d4553 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -247,15 +247,7 @@ add_files_recursive (notmuch_database_t *notmuch,
directory = notmuch_database_get_directory (notmuch, path);
db_mtime = notmuch_directory_get_mtime (directory);
-if (db_mtime == 0) {
- new_directory = TRUE;
- db_files = NULL;
- db_subdirs = NULL;
-} else {
- new_directory = FALSE;
- db_files = notmuch_directory_get_child_files (directory);
- db_subdirs = notmuch_directory_get_child_directories (directory);
-}
+new_directory = db_mtime ? FALSE : TRUE;
/* If the database knows about this directory, then we sort based
* on strcmp to match the database sorting. Otherwise, we can do
@@ -328,6 +320,11 @@ add_files_recursive (notmuch_database_t *notmuch,
if (fs_mtime == db_mtime)
goto DONE;
+if (!new_directory) {
+ db_files = notmuch_directory_get_child_files (directory);
+ db_subdirs = notmuch_directory_get_child_directories (directory);
+}
+
/* Pass 2: Scan for new files, removed files, and removed directories. */
for (i = 0; i < num_fs_entries; i++)
{
--
1.7.3.4
always encrypting messages to self [was: Re: new "crypto" branch providing full PGP/MIME support]
I just love seeing all those yellow signatures. It reminds me to meet you all in real life to verify your keys :-). Thanks for implementing this, the whole lot of you. It works really well. Sebastian -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110204/66dd73ea/attachment.pgp>
no quoted messages if fcc folder cannot be created.
i tried running emacs -Q -f notmuch and replying to a message. Since i didn't have my emacs config, it wanted to create the default sent folder in ~/mail/sent if i told it "no, don't create it" when prompted (during the setup of the reply message) then the body of the replied-to message doesn't show up. If ~/mail/sent is actually a file (not a folder) so that the fcc folder cannot be created, then i get the same problem (the replied-to message doesn't show up quoted in the body of the new *mail* buffer). sorry i haven't been able to track it down more than that. to replicate: mv ~/mail/sent ~/mail/sent.bak touch ~/mail/sent emacs -Q -f notmuch hth, --dkg -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110204/bef43091/attachment.pgp>
new "crypto" branch providing full PGP/MIME support
On Wed, 02 Feb 2011 17:18:45 -0800, Jameson Rollins wrote: > > Please test and provide feedback. I would really like to see this > series merged into the mainline for the next release, if at all > possible. I reported some pretty weird experiences yesterday on IRC with replies not working. It turns out they were caused by having old versions of xapian installed in /usr/local (which I think might have caused some mixup with headers and libraries being different versions). The decryption is working ok for me now (aside from the issue I mentioned already with unknown encrypted+signed). d tl;dr: yesterdays weirdness was not the fault of J. Rollins. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 315 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110204/6e9accc7/attachment.pgp>
new "crypto" branch providing full PGP/MIME support
Hey, folks. I've pushed some improvements to the "crypto" branch that: * add support for replying to encrypted messages * don't show sigstatus button for unsigned encrypted messages As always, please let me know encounter any problems. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110204/074cd771/attachment.pgp>
new "crypto" branch providing full PGP/MIME support
On 02/04/2011 11:59 AM, micah anderson wrote: > On Thu, 03 Feb 2011 14:52:01 -0500, Daniel Kahn Gillmor fifthhorseman.net> wrote: >> 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. so you hold key A, the sender holds key B, they encrypt the message with B, and then revoke key B, and then you try to read the message (without holding key B)? or are you saying you hold key A, sender holds key B, they encrypt to A, *sign* the message with B, and then revoke B? If it's this case, does the same thing happen even if the message is not encrypted? Sorry for the nit-picking pedantry here -- I'm trying to get a clear workflow for a test case. > 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. and if you're presented with only one key, you will just accept that one? that puts you at the mercy of the network (or the keyserver operator at least, and we can't all have the luxury of being or knowing the keyserver operator directly). If you're arguing "i would like to be able to recognize the key by 32-bit key ID" i don't think it's actually possible to do so because of the spoofability; a tool that provides cryptographic assurances should discourage attempts to make the user vulnerable to spoofing. If you're saying we should remove the 64-bit keyID entirely and just say "signature from unknown, non-validated key", i think that's a defensible position, though it's not one i would take. >> 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. and as i said above, i think this is a mistake if we're trying to provide tools that give cryptographic assurances. thanks for the testing and the corner cases! --dkg -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110204/344de8a8/attachment-0001.pgp>
new "crypto" branch providing full PGP/MIME support
On Thu, 03 Feb 2011 13:02:41 -0800, Jameson Rollins wrote: > > Can we pass the decrypted text to message mode on a reply? > Yeah, some folks pointed this out on #notmuch this morning. The > decryption is only happening in notmuch-show, but we need to do it in > notmuch-reply as well for the decrypted text to show up in the reply. > I'm working on it now. Great news, thanks! Also: another confirmation for the revoked/expired key behaviour. Emacs UI just reports: json-read-string: Wrong type argument: characterp, :json-eof Let me know if you need any samples of misbehaving mails. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110204/e63c87db/attachment.pgp>
new "crypto" branch providing full PGP/MIME support
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>
new "crypto" branch providing full PGP/MIME support
On Fri, 04 Feb 2011 13:12:27 -0400, David Bremner wrote: > I reported some pretty weird experiences yesterday on IRC with replies > not working. It turns out they were caused by having old versions of > xapian installed in /usr/local (which I think might have caused some > mixup with headers and libraries being different versions). > > The decryption is working ok for me now (aside from the issue I > mentioned already with unknown encrypted+signed). ... > tl;dr: yesterdays weirdness was not the fault of J. Rollins. phew! Although there remains the issue of replying to encrypted messages, since notmuch-reply was not modified to decrypt messages before replying. I'm working on that now. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110204/dbef16ec/attachment.pgp>
new "crypto" branch providing full PGP/MIME support
On Fri, 04 Feb 2011 12:09:48 +, Darren McGuicken wrote: > On Thu, 03 Feb 2011 13:02:41 -0800, Jameson Rollins finestructure.net> wrote: > > > Can we pass the decrypted text to message mode on a reply? > > Yeah, some folks pointed this out on #notmuch this morning. The > > decryption is only happening in notmuch-show, but we need to do it in > > notmuch-reply as well for the decrypted text to show up in the reply. > > I'm working on it now. > > Great news, thanks! Thanks for the feedback! > Also: another confirmation for the revoked/expired key behaviour. Emacs > UI just reports: > > json-read-string: Wrong type argument: characterp, :json-eof > > Let me know if you need any samples of misbehaving mails. Yeah, I've found some emails that are doing this as well. I'm looking in to what we can do to mitigate the problem, which I think is ultimately a problem in GMime. The json output should not be breaking, though, so that I will definitely fix. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110204/a14fe560/attachment.pgp>
always encrypting messages to self [was: Re: new "crypto" branch providing full PGP/MIME support]
On Fri, 04 Feb 2011 14:04:23 +0100, Sebastian Spaeth wrote: > I just love seeing all those yellow signatures. It reminds me to meet > you all in real life to verify your keys :-). > > Thanks for implementing this, the whole lot of you. It works really > well. Yes! I'm really glad you're finding it useful. Hopefully you're seeing some green fully-valid-userid sigs in there as well... jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110204/985058d7/attachment.pgp>
new "crypto" branch providing full PGP/MIME support
On Fri, 04 Feb 2011 08:24:38 -0400, David Bremner wrote: > On Wed, 02 Feb 2011 17:18:45 -0800, Jameson Rollins finestructure.net> wrote: > > Hi, all. I have pushed a new branch called "crypto" to my notmuch > > repository [0]. This branch provides full support for PGP/MIME signed > > and encrypted messages, including emacs UI support. It has been applied > > on top of cworth's current master (21e97c50). It includes the > > following: > > > > For a signed and encrypted message, if the signing key can't be found, > one just gets: > > [ multipart/encrypted: decryption error ] > > which is a bit mystifying. At least gpg on the command line will > decrypt the message and print a warning about the signature. So I need to look at this closer, but I think this is a GMime problem. That error message is generated when the GMime decryption code returns NULL for the decrypted part. I'll try to make a test case for this, and file a bug with GMime upstream. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110204/ce9426d4/attachment.pgp>
new "crypto" branch providing full PGP/MIME support
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: > For a signed and encrypted message, if the signing key can't be found, one just gets: [ multipart/encrypted: decryption error ] which is a bit mystifying. At least gpg on the command line will decrypt the message and print a warning about the signature. All the best, and thanks for working on this, d -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 315 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110204/92235fa5/attachment-0001.pgp>
Re: new crypto branch providing full PGP/MIME support
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
Re: new crypto branch providing full PGP/MIME support
On Wed, 02 Feb 2011 17:18:45 -0800, Jameson Rollins jroll...@finestructure.net wrote: Please test and provide feedback. I would really like to see this series merged into the mainline for the next release, if at all possible. I reported some pretty weird experiences yesterday on IRC with replies not working. It turns out they were caused by having old versions of xapian installed in /usr/local (which I think might have caused some mixup with headers and libraries being different versions). The decryption is working ok for me now (aside from the issue I mentioned already with unknown encrypted+signed). d tl;dr: yesterdays weirdness was not the fault of J. Rollins. pgpnUrpra2H8q.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: new crypto branch providing full PGP/MIME support
On Fri, 04 Feb 2011 08:24:38 -0400, David Bremner brem...@unb.ca wrote: On Wed, 02 Feb 2011 17:18:45 -0800, Jameson Rollins jroll...@finestructure.net wrote: Hi, all. I have pushed a new branch called crypto to my notmuch repository [0]. This branch provides full support for PGP/MIME signed and encrypted messages, including emacs UI support. It has been applied on top of cworth's current master (21e97c50). It includes the following: For a signed and encrypted message, if the signing key can't be found, one just gets: [ multipart/encrypted: decryption error ] which is a bit mystifying. At least gpg on the command line will decrypt the message and print a warning about the signature. So I need to look at this closer, but I think this is a GMime problem. That error message is generated when the GMime decryption code returns NULL for the decrypted part. I'll try to make a test case for this, and file a bug with GMime upstream. jamie. pgp44IkU2p9Dy.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: always encrypting messages to self [was: Re: new crypto branch providing full PGP/MIME support]
On Fri, 04 Feb 2011 14:04:23 +0100, Sebastian Spaeth sebast...@sspaeth.de wrote: I just love seeing all those yellow signatures. It reminds me to meet you all in real life to verify your keys :-). Thanks for implementing this, the whole lot of you. It works really well. Yes! I'm really glad you're finding it useful. Hopefully you're seeing some green fully-valid-userid sigs in there as well... jamie. pgppy6NrmUVFM.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: new crypto branch providing full PGP/MIME support
On 02/04/2011 11:59 AM, micah anderson wrote: On Thu, 03 Feb 2011 14:52:01 -0500, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: 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. so you hold key A, the sender holds key B, they encrypt the message with B, and then revoke key B, and then you try to read the message (without holding key B)? or are you saying you hold key A, sender holds key B, they encrypt to A, *sign* the message with B, and then revoke B? If it's this case, does the same thing happen even if the message is not encrypted? Sorry for the nit-picking pedantry here -- I'm trying to get a clear workflow for a test case. 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. and if you're presented with only one key, you will just accept that one? that puts you at the mercy of the network (or the keyserver operator at least, and we can't all have the luxury of being or knowing the keyserver operator directly). If you're arguing i would like to be able to recognize the key by 32-bit key ID i don't think it's actually possible to do so because of the spoofability; a tool that provides cryptographic assurances should discourage attempts to make the user vulnerable to spoofing. If you're saying we should remove the 64-bit keyID entirely and just say signature from unknown, non-validated key, i think that's a defensible position, though it's not one i would take. 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. and as i said above, i think this is a mistake if we're trying to provide tools that give cryptographic assurances. thanks for the testing and the corner cases! --dkg signature.asc Description: OpenPGP digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: new crypto branch providing full PGP/MIME support
On Fri, 04 Feb 2011 12:09:48 +, Darren McGuicken mailing-notm...@fernseed.info wrote: On Thu, 03 Feb 2011 13:02:41 -0800, Jameson Rollins jroll...@finestructure.net wrote: Can we pass the decrypted text to message mode on a reply? Yeah, some folks pointed this out on #notmuch this morning. The decryption is only happening in notmuch-show, but we need to do it in notmuch-reply as well for the decrypted text to show up in the reply. I'm working on it now. Great news, thanks! Thanks for the feedback! Also: another confirmation for the revoked/expired key behaviour. Emacs UI just reports: json-read-string: Wrong type argument: characterp, :json-eof Let me know if you need any samples of misbehaving mails. Yeah, I've found some emails that are doing this as well. I'm looking in to what we can do to mitigate the problem, which I think is ultimately a problem in GMime. The json output should not be breaking, though, so that I will definitely fix. jamie. pgpMreBm1wDBF.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: new crypto branch providing full PGP/MIME support
On Fri, 04 Feb 2011 13:12:27 -0400, David Bremner brem...@unb.ca wrote: I reported some pretty weird experiences yesterday on IRC with replies not working. It turns out they were caused by having old versions of xapian installed in /usr/local (which I think might have caused some mixup with headers and libraries being different versions). The decryption is working ok for me now (aside from the issue I mentioned already with unknown encrypted+signed). ... tl;dr: yesterdays weirdness was not the fault of J. Rollins. phew! Although there remains the issue of replying to encrypted messages, since notmuch-reply was not modified to decrypt messages before replying. I'm working on that now. jamie. pgp5qydZCj9Wm.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
no quoted messages if fcc folder cannot be created.
i tried running emacs -Q -f notmuch and replying to a message. Since i didn't have my emacs config, it wanted to create the default sent folder in ~/mail/sent if i told it no, don't create it when prompted (during the setup of the reply message) then the body of the replied-to message doesn't show up. If ~/mail/sent is actually a file (not a folder) so that the fcc folder cannot be created, then i get the same problem (the replied-to message doesn't show up quoted in the body of the new *mail* buffer). sorry i haven't been able to track it down more than that. to replicate: mv ~/mail/sent ~/mail/sent.bak touch ~/mail/sent emacs -Q -f notmuch find a message, hit 'r' hth, --dkg signature.asc Description: OpenPGP digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
