Use of strcasestr

Twas brillig at 15:58:10 12.04.2010 UTC+02 when tom at dbservice.com did gyre and gimble: TC> In 4fd9ea0 (guess From address from Received headers, 2010-04-06) you introduced TC> strcasestr, which is not portable, see 82e47ec (notmuch reply: Use strstr TC> instead of strcasestr for

Re: Use of strcasestr

Twas brillig at 15:58:10 12.04.2010 UTC+02 when t...@dbservice.com did gyre and gimble: TC In 4fd9ea0 (guess From address from Received headers, 2010-04-06) you introduced TC strcasestr, which is not portable, see 82e47ec (notmuch reply: Use strstr TC instead of strcasestr for portability.,

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

Twas brillig at 16:51:17 16.12.2009 UTC-07 when bdale at gag.com did gyre and gimble: >> But the above sounds like the List-Id header is unreliable enough to >> be useless. BG> FWIW, that does not match my experience. Yeah. This mail just arrived to my "main" folder instead of "notmuch"

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

Twas brillig at 16:39:50 04.12.2009 UTC-08 when cworth at cworth.org did gyre and gimble: CW> But when viewing an actual message, I'm still planning on having CW> notmuch just return an arbitrary filename from the list of CW> filenames associated with that message. Does anyone see any

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

Twas brillig at 10:35:27 04.12.2009 UTC-08 when cworth at cworth.org did gyre and gimble: >> The only problem with Cc is that Mailman suppresses duplicate >> messages and hence there is no List-Id: on message. CW> But the above sounds like the List-Id header is unreliable enough CW> to be

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

Twas brillig at 10:05:05 04.12.2009 UTC-08 when cworth at cworth.org did gyre and gimble: CW> Plus, notmuch already handles duplicate mail just fine, (in that the CW> user only sees one copy at least). And I tag my mail differently when CW> one of my addresses appears on the CC list, so I

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

Twas brillig at 10:05:05 04.12.2009 UTC-08 when cwo...@cworth.org did gyre and gimble: CW Plus, notmuch already handles duplicate mail just fine, (in that the CW user only sees one copy at least). And I tag my mail differently when CW one of my addresses appears on the CC list, so I

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

Twas brillig at 16:39:50 04.12.2009 UTC-08 when cwo...@cworth.org did gyre and gimble: CW But when viewing an actual message, I'm still planning on having CW notmuch just return an arbitrary filename from the list of CW filenames associated with that message. Does anyone see any problem CW

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

still does not handle copying files (which is harmless, database will point to the last copy of message found during 'notmuch new') and deleting files (which is more serious, as dangling entries will show up in searches). Signed-off-by: Mikhail Gusarov --- lib/database.cc | 32

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

still does not handle copying files (which is harmless, database will point to the last copy of message found during 'notmuch new') and deleting files (which is more serious, as dangling entries will show up in searches). Signed-off-by: Mikhail Gusarov dotted...@dottedmag.net --- lib/database.cc

[notmuch] [PATCH 2/3] add checking for zlib development libraries to configure script

Twas brillig at 18:57:36 28.11.2009 UTC-05 when jrollins at finestructure.net did gyre and gimble: JGR> + sudo apt-get install libxapian-dev libgmime-2.4-dev JGR> libtalloc-dev libz-dev Proper fix is to fix libgmime-2.4.pc upstream to stop exposing -lz -- http://fossarchy.blogspot.com/

[notmuch] [PATCH] Use libgcrypt for hashing.

Twas brillig at 21:28:03 27.11.2009 UTC-06 when jeff at ocjtech.us did gyre and gimble: JCO> Instead of including a private implementation of the SHA1 hash xserver went this road, and now it has --with-sha1=libc|libmd|libgcrypt|libcrypto|libsha1|CommonCrypto in configure. JCO> This means

[notmuch] Using notmuch from Ruby, Python, et al.

Twas brillig at 18:55:28 27.11.2009 UTC-08 when cworth at cworth.org did gyre and gimble: >> Q: Why are my replies five sentences or less? >> A: http://five.sentenc.es/ CW> There---just five this time. :-) I imagine hook that counts the number of sentences and inserts proper signature :)

[notmuch] [PATCH] Handle message renames in mail spool

still does not handle copying files (which is harmless, database will point to the last copy of message found during 'notmuch new') and deleting files (which is more serious, as dangling entries will show up in searches). Signed-off-by: Mikhail Gusarov --- lib/database.cc | 32

[notmuch] [PATCH] Handle message renames in mail spool

Twas brillig at 07:40:15 26.11.2009 UTC-08 when cworth at cworth.org did gyre and gimble: CW> I *really* want this patch in, since I think a lot of current users CW> would really benefit from it. I only see one big problem with it: Did you test the performance hit caused by disabling mtime

[notmuch] Notmuch doesn't index new mails when mail location contains symlinks

Twas brillig at 16:03:00 23.11.2009 UTC+01 when jed at 59A2.org did gyre and gimble: JB> The real solution is for notmuch to check mtime of whatever the JB> symlink's target. It does exactly this AFACT, stat() everywhere, not lstat(). -- http://fossarchy.blogspot.com/ -- next

[notmuch] Notmuch doesn't index new mails when mail location contains symlinks

Twas brillig at 16:01:41 23.11.2009 UTC+01 when tassilo at member.fsf.org did gyre and gimble: >>> Probably mail does not get indexed due to mtime checks. Please try >>> whether touch'ing directory with mailboxes makes it work. >> No, it seems that doesn't help either. TH> Ah, I'm stupid!

[notmuch] Notmuch doesn't index new mails when mail location contains symlinks

Twas brillig at 14:55:40 23.11.2009 UTC+01 when tassilo at member.fsf.org did gyre and gimble: TH> Whenever I delete those symlinks and created them anew, the new TH> mails get indexed with the next "notmuch new". Of course, I could TH> create a script that does exactly that, but there

[notmuch] [PATCH] Handle message renames in mail spool

still does not handle copying files (which is harmless, database will point to the last copy of message found during 'notmuch new') and deleting files (which is more serious, as dangling entries will show up in searches). Signed-off-by: Mikhail Gusarov --- lib/database.cc | 21

[notmuch] [PATCH] Makefile: Magic silent rules.

Twas brillig at 20:32:20 21.11.2009 UTC+00 when chris at chris-wilson.co.uk did gyre and gimble: CW> Use the facilities of GNU make to create a magic function that will CW> on the first invocation print a description of how to enable CW> verbose compile lines and then print the quiet rule.

[notmuch] [PATCH] Makefile: Magic silent rules.

Twas brillig at 19:02:22 21.11.2009 UTC+00 when chris at chris-wilson.co.uk did gyre and gimble: CW> Use the facilities of GNU make to create a magic function that will CW> on the first invocation print a description of how to enable CW> verbose compile lines and then print the quiet rule.

[notmuch] [PATCH] RFC: quiet make

Twas brillig at 14:16:52 21.11.2009 UTC+01 when cworth at cworth.org did gyre and gimble: CW> Meanwhile, the feature I've always wanted with systems like this is CW> to document to the user that there's the possibility of adding a CW> "V=1" to the command line to get the full output. I have

[notmuch] [PATCH] RFC: quiet make

I don't entirely like duplicating every command line in makefile, so this patch is RFC. Someone with bigger Make-fu than mine probably knows a better way. Signed-off-by: Mikhail Gusarov --- Makefile | 36 Makefile.local | 10 ++ lib

[notmuch] [PATCH] Add notmuch.1.gz to files to be cleaned

Signed-off-by: Mikhail Gusarov --- Makefile.local |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile.local b/Makefile.local index ecd4ceb..bf81c03 100644 --- a/Makefile.local +++ b/Makefile.local @@ -45,4 +45,4 @@ install-emacs: install emacs install

[notmuch] [PATCH] Allow to redefine notmuch binary name and path in elisp mode

Signed-off-by: Mikhail Gusarov --- notmuch.el | 13 - 1 files changed, 8 insertions(+), 5 deletions(-) diff --git a/notmuch.el b/notmuch.el index 1fc54c3..f97950f 100644 --- a/notmuch.el +++ b/notmuch.el @@ -71,6 +71,9 @@ pattern can still test against the entire line

[notmuch] [PATCH] Handle rename of message file

Twas brillig at 18:06:09 18.11.2009 UTC-08 when keithp at keithp.com did gyre and gimble: KP> Checking for new files is easy; notmuch already does that, and so KP> handling renames doesn't seem all that difficult. Except rename does not change mtime of file, and so it won't be picked up by

[notmuch] [PATCH] Handle rename of message file

Twas brillig at 02:08:15 19.11.2009 UTC+01 when cworth at cworth.org did gyre and gimble: CW> I believe you said in IRC that this patch is not ready yet. Yes. CW> I'd love to hear more from you on any experiments/ideas you have in CW> this area. It would be a really nice feature to have,

[notmuch] [PATCH] Handle rename of message file

If message file has been renamed, just update filename in the DB. Signed-off-by: Mikhail Gusarov --- lib/database.cc | 21 - 1 files changed, 12 insertions(+), 9 deletions(-) diff --git a/lib/database.cc b/lib/database.cc index 3c8d626..c4eb8b6 100644 --- a/lib

[notmuch] Working with Maildir storage?

Twas brillig at 15:33:01 17.11.2009 UTC-05 when lars at seas.harvard.edu did gyre and gimble: LK> Is the list archived anywhere? The obvious archives LK> (http://notmuchmail.org/pipermail/notmuch/) aren't available, and I LK> think I subscribed too late to get the patch (I only just saw the

[notmuch] Working with Maildir storage?

Twas brillig at 14:00:54 17.11.2009 UTC-05 when lars at seas.harvard.edu did gyre and gimble: LK> Resulted in 4604 lines of errors along the lines of: LK> Error opening LK> /home/lars/Mail/read-messages.2008/cur/1246413773.24928_27334.hostname,U=3026:2,S: LK> Too many open files

[notmuch] [PATCH 2/2] Include to get uint32_t in C++ file with gcc 4.4

Signed-off-by: Mikhail Gusarov --- lib/message.cc |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/lib/message.cc b/lib/message.cc index 72c350f..a4b090b 100644 --- a/lib/message.cc +++ b/lib/message.cc @@ -21,6 +21,8 @@ #include "notmuch-private.h" #include

[notmuch] [PATCH 1/2] Close message file after parsing message headers

Keeping unused files open helps to see "Too many open files" often. Signed-off-by: Mikhail Gusarov --- lib/message-file.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/lib/message-file.c b/lib/message-file.c index 8a3f8ee..197ab01 100644 --- a/lib/mess