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 portabili
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
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"
one
Twas brillig at 16:51:17 16.12.2009 UTC-07 when bd...@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"
one, a
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 problem
Twas brillig at 13:52:20 04.12.2009 UTC-05 when mdorman at ironicdesign.com did
gyre and gimble:
MAD> Err, this makes no sense. How can Mailman have any knowledge of,
MAD> and therefore "do anything" to any message that came by way of a
MAD> CC?
for each subscriber:
if subscriber.email in
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 u
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 def
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
C
Twas brillig at 13:52:20 04.12.2009 UTC-05 when mdor...@ironicdesign.com did
gyre and gimble:
MAD> Err, this makes no sense. How can Mailman have any knowledge of,
MAD> and therefore "do anything" to any message that came by way of a
MAD> CC?
for each subscriber:
if subscriber.email in me
Twas brillig at 10:35:27 04.12.2009 UTC-08 when cwo...@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 usel
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 defini
tmuch 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/dat
tmuch 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/dat
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/
--
Twas brillig at 18:57:36 28.11.2009 UTC-05 when jroll...@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/
pgp
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 les
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 :)
-
Twas brillig at 21:28:03 27.11.2009 UTC-06 when j...@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 less c
Twas brillig at 18:55:28 27.11.2009 UTC-08 when cwo...@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 :)
--
tmuch 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/dat
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 ch
tmuch 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/dat
Twas brillig at 07:40:15 26.11.2009 UTC-08 when cwo...@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 check
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
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! I
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 shoul
tmuch 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/dat
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.
U
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.
U
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
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 ++
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
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
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 'n
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, (p
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
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
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
See
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
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
41 matches
Mail list logo