Re: [PATCH] emacs: Add notmuch-hello.el, a friendly frontend to notmuch
On Mon, 12 Apr 2010, David Edmondson wrote: > commit e55dc251b9e8001fe16873fadac565563e606d69 > Author: David Edmondson > Date: Mon Apr 12 11:12:23 2010 +0100 > > emacs: Add notmuch-hello.el, a friendly frontend to notmuch Hi dme, thanks for the great patch. For next time, could you plese use 'git format-patch' for generating patches for sending in email? If I pipe your message to 'git am', all the above text becomes a part of commit message. -Michal ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Add notmuch-hello.el, a friendly frontend to notmuch
On Tue, 13 Apr 2010 12:25:43 +0200, Michal Sojka wrote: > For next time, could you plese use 'git format-patch' for generating > patches for sending in email? If I pipe your message to 'git am', all > the above text becomes a part of commit message. Will do. dme. -- David Edmondson, http://dme.org ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Add simplistic reimplementation of strcasestr to compat library
On Tue, 13 Apr 2010 15:59:24 +1000, Anthony Towns wrote: > On Tue, Apr 13, 2010 at 14:10, Dirk Hohndel wrote: > > +/* the semantic here actually puzzles me: > > + how can haystack be const char * - yet the return value is char * > > + after all, it points to a sub-string of haystack... */ > > Dunno if this is a question from the original source, but the answer No, that was me being puzzled :-) > if anyone's interested is probably because C doesn't have templates -- > you'd ideally like to have it treated as: > > char *strcasestr(char *haystack, const char *needle); > > for when you're doing a search and replace on the needle (say), and: > > const char *strcasestr(const char *haystack, const char *needle); > > for when you're doing a search for the needle in something you can't > modify. But C isn't clever enough to let you say that with just one > function (and no fancy #defines), so you have to drop some of the > typechecking with the (char*) cast on the return value if you want to > handle both use cases, without the compiler complaining about > const->non-const conversions in otherwise correct code in one case or > the other. That makes sense. Thanks /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: when archiving move the cursor depending on the sort order.
The current hardcoded behaviour will not take you to the next unread thread when the sort order is set to newer-first from the default of older-first. Signed-off-by: Servilio Afre Puentes --- emacs/notmuch.el |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 517c53a..728aa2b 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -572,7 +572,9 @@ thread or threads in the current region." This function advances the next thread when finished." (interactive) (notmuch-search-remove-tag-thread "inbox") - (forward-line)) + (if notmuch-search-oldest-first + (forward-line) +(previous-line))) (defun notmuch-search-process-sentinel (proc msg) "Add a message to let user know when \"notmuch search\" exits" -- 1.7.0.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Extend the archive function to operate on regions too.
Signed-off-by: Servilio Afre Puentes --- emacs/notmuch.el | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 517c53a..4d4971f 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -264,7 +264,7 @@ For a mouse binding, return nil." (define-key map "f" 'notmuch-search-filter) (define-key map [mouse-1] 'notmuch-search-show-thread) (define-key map "*" 'notmuch-search-operate-all) -(define-key map "a" 'notmuch-search-archive-thread) +(define-key map "a" 'notmuch-search-archive-thread-or-region) (define-key map "-" 'notmuch-search-remove-tag) (define-key map "+" 'notmuch-search-add-tag) (define-key map (kbd "RET") 'notmuch-search-show-thread) @@ -359,7 +359,7 @@ participants in the thread, a representative subject line, and any tags). Pressing \\[notmuch-search-show-thread] on any line displays that thread. The '\\[notmuch-search-add-tag]' and '\\[notmuch-search-remove-tag]' -keys can be used to add or remove tags from a thread. The '\\[notmuch-search-archive-thread]' key +keys can be used to add or remove tags from a thread. The '\\[notmuch-search-archive-thread-or-region]' key is a convenience for archiving a thread (removing the \"inbox\" tag). The '\\[notmuch-search-operate-all]' key can be used to add or remove a tag from all threads in the current buffer. @@ -566,12 +566,12 @@ thread or threads in the current region." (notmuch-search-remove-tag-region tag beg end)) (notmuch-search-remove-tag-thread tag -(defun notmuch-search-archive-thread () - "Archive the currently selected thread (remove its \"inbox\" tag). +(defun notmuch-search-archive-thread-or-region () + "Archive the currently selected thread or region (remove its \"inbox\" tag). This function advances the next thread when finished." (interactive) - (notmuch-search-remove-tag-thread "inbox") + (notmuch-search-remove-tag "inbox") (forward-line)) (defun notmuch-search-process-sentinel (proc msg) -- 1.7.0.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Store thread ids for messages that we haven't seen yet
On Sat, 13 Mar 2010 16:27:57 -0500, James Westby wrote: > This allows us to thread messages even when we receive them out of > order, or never receive the root. Thanks for this patch, James! It's especially nice to have the fix come in with additions to the test suite as well. I did split up the commit so the addition to the test suite happens first. That way it's easy to test the test itself, (verifying that it fails before the fix, and then passes after the fix). I also added a few documentation and other cleanups as follow-on commits. Hopefully, they don't change the logic at all, but make things easier to understand. So that's all pushed. Then, I started implementing support for retroactively storing thread_ids for non-existing messages references in already-existing messages. It took me perhaps too long that a change like that, (while useful), is too invasive for the current 0.2 release, and not essential for this particular feature. So I've postponed that part at least. I hope to make a database-schema upgrade a key part of a release in a couple of cycles, (for this feature and for "list:" and "folder:"). -Carl pgpPdCIiiakxD.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] json_quote_str should handle non-ASCII characters
On Thu, 04 Mar 2010 11:40:03 +0100, Gregor Hoffleit wrote: > The current code in json_quote_str() only accepts strict printable ASCII > code points (i.e. 32-127), all other code points are dropped from the > JSON output. > > This patch accepts code points 32-255. Thanks, Gregor! I've pushed this patch out now. And I noted in our TODO file that we really should add some tests to the test suite to exercise our --format=json code paths. It would be nice to ensure we don't have any regressions in this area later. -Carl pgpSjOjto3stT.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Store thread ids for messages that we haven't seen yet
On Tue, 13 Apr 2010 08:20:48 -0700, Carl Worth wrote: > Thanks for this patch, James! It's especially nice to have the fix come > in with additions to the test suite as well. Thanks for including a test suite I could add to! > I did split up the commit so the addition to the test suite happens > first. That way it's easy to test the test itself, (verifying that it > fails before the fix, and then passes after the fix). Your choice. I prefer putting them in the same commit to be more self-documenting, and then using the capabilities of my VCS to verify the change if i desire. > I also added a few documentation and other cleanups as follow-on > commits. Hopefully, they don't change the logic at all, but make things > easier to understand. > > So that's all pushed. Great, thanks. > Then, I started implementing support for retroactively storing > thread_ids for non-existing messages references in already-existing > messages. It took me perhaps too long that a change like that, (while > useful), is too invasive for the current 0.2 release, and not essential > for this particular feature. This would fix up threads for all existing messages? Probably a good thing to have, but not that important to me. In my case I can always open the bug in my browser if I want to see the full conversation. > So I've postponed that part at least. I hope to make a database-schema > upgrade a key part of a release in a couple of cycles, (for this > feature and for "list:" and "folder:"). Cool, I look forward to it. Thanks, James ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Add count command to manual page
On Thu, 18 Mar 2010 21:43:57 +0100, Sandra Snan wrote: > Just found out that I’ve been piping things through wc for no reason. > Heh. Here’s a quick patch, if you want to add this to the manual page. Yikes! I'm sorry that we had such a big omission in our manual page. And thanks for sending the patch. I'm sorry that I was so behind on the mailing-list backlog that I didn't notice this and apply it right away. Instead, during some recent updates to the manual page, I noticed that this was missing and already added it. But please keep suggestions for improvement coming! -Carl pgpPfkyIEc5qw.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Fix typo in notmuch.h documentation regarding database open modes
On Fri, 26 Mar 2010 18:39:17 +, Michael Forney wrote: > --- > lib/notmuch.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Thanks so much, Michael! I added a paragraph of "why" to the commit message and pushed this out. -Carl pgpWAHYWoqiBI.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Prevent data loss caused by SIGINT during notmuch new
On Tue, 30 Mar 2010 10:23:23 +0200, Michal Sojka wrote: > When Ctrl-C is pressed in a wrong time during notmuch new, it can lead > to removal of messages from the database even if the files were not > removed. > > It happened at least once to me. > > Signed-off-by: Michal Sojka Thanks so much, Michal! This was a very bad bug that I'm sure I introduced myself when implementing rename support. Thanks to Sebastian for reminding me to pick this up for the 0.2 release. And, everyone, if I'm behind on patches, (which has always been the case so far with this project...), please feel free to make plenty of noise when there are known fixes for data-loss bugs. We really shouldn't let those sit for a couple of weeks! -Carl pgpv1jX4K9zi0.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Do not segfault on empty mime parts
On Tue, 2 Mar 2010 16:31:28 +0100, "martin f. krafft" wrote: > notmuch previously unconditionally checked mime parts for various > properties, but not for NULL, which is the case if libgmime encounters > an empty mime part. Thanks for the fix. > Upon encounter of an empty mime part, the following is printed to > stderr (the second line due to my patch): > > (process:17197): gmime-CRITICAL **: g_mime_message_get_mime_part: assertion > `GMIME_IS_MESSAGE (message)' failed > Warning: Not indexing empty mime part. That message is all quite ugly. I'm perpetually annoyed by libraries that claim to detect major problems, (even "CRITICAL" problems!), and just print messages and march along. Either there *is* a critical problem here, in which case the library should halt after printing the message, (see for example, what notmuch does with its INTERNAL_ERROR macro), or there's no problem at all and the code should operate correctly without these obnoxious messages. Anyway, I've put a note into TODO that we should do the following (in order): 1. Add a test case to trigger this message 2. File a bug against GMime to eliminate its portion of the message 3. Remove the notmuch portion of the message -Carl pgpyeXeAyFp1P.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Plans for the 0.2 release (this week)
On Thu, 08 Apr 2010 09:47:00 +0200, "Sebastian Spaeth" wrote: > First of all, thanks for the great work Carl. I have to admit I was > getting nervous about the backlog of patches, but your recent committing > binge (you did say your work patterns are bursty :-)) made me very happy. You're quite welcome. And the big backlog was making me nervous too. I'm not sure that the backlog has gotten any smaller yet, but I'm really happy with where things are going. I seem to have created a code hydra, where every time I merge one patch, people get excited to and send me three more patches. > That having said, I am glad to meet your expectation: "I expect people > to remind me of their favorite features that haven't been merged..." > :-) Thanks for the very useful list, Sebastian. These are all merged now, (as mentioned in the replies I've made to the original messages with the patches). > > * Some library additions (move_to_first for the iterators, > +1! That one I've got noted on a separate list. > All the rest souds very good. I really do need a thread-splitting feature in order to use notmuch as my feature tracker. A list like the above of "6 trivial patches to merge" is easy to handle as a single item. I can send a message like this one saying "I'm done with this list". But several different people did reply to my original "plans for 0.2" call for features. So the single thread I have for this in my "notmuch merge window" search is not doing the trick. -Carl pgp4B79MDzwrF.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Plans for the 0.2 release (this week)
On Thu, 08 Apr 2010 09:52:21 -0400, Jameson Rollins wrote: > I would really like to see the patch in spaetz/issue15-handle-fcc-bcc > applied soon. This is the lingering issue of bcc'ing the primary email > address in notmuch replies, which I think really needs to be removed. > > Let me know if there are any issues. I'm pretty sure this will apply > cleanly against the head without a rebase. I'm happy to remove the Bcc thing, but only *after* we have an Fcc approach integrated into the emacs client by default, (without users having to configure it, download python scripts, etc.). And yes, I know the current Bcc approach is still quite useless, because it only triggers on replies, (and not when composing a new message from the emacs client). I'm looking forward to seeing this all fixed, but I haven't yet seen a "packaged" solution. -Carl pgpGoaDjovWLS.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] notmuch.el: quote args in notmuch-show to facilitate remote use
On Sun, 24 Jan 2010 15:22:33 -0500, Jesse Rosenthal wrote: > Put single-quotes around the argument of the `show --entire-thread' command > in notmuch-show. Thanks for this, Jesse! I've merged this change now, and (as documented) I don't notice any change. I am quite interested in playing with the "use notmuch over ssh" stuff you've been doing, (and that you described in the original follow-up to this patch). Perhaps you (or someone else) would like to maintain a wiki page showing how that can be used until we get remote support more properly integrated into notmuch itself. Thanks again, -Carl pgpEODyKyLHhU.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] First tests for JSON output and UTF-8 in mail body and subject
The test suite doesn't yet cover --format=json output nor UTF-8 in subject or body. This patch starts with test cases for 'search --format=json' and 'show --format=json'. Furthermore, it has test cases for a search for a UTF-8 string in a mail body for a UTF-8 string in a mail subject. Finally, it has a test case for --format=json with UTF-8 messages, demonstrating the fix in 1267697893-sup-4...@sam.mediasupervision.de. --- test/notmuch-test | 38 ++ 1 files changed, 38 insertions(+), 0 deletions(-) diff --git a/test/notmuch-test b/test/notmuch-test index 1c5191b..b2a0756 100755 --- a/test/notmuch-test +++ b/test/notmuch-test @@ -146,7 +146,7 @@ add_message () } NOTMUCH_IGNORED_OUTPUT_REGEXP='^Processed [0-9]*( total)? file|Found [0-9]* total file' -NOTMUCH_THREAD_ID_SQUELCH='s/thread:/thread:XXX/' +NOTMUCH_THREAD_ID_SQUELCH='s/thread:/thread:XXX/;s/"thread": "",/"thread": "XXX",/' execute_expecting () { args=$1 @@ -348,6 +348,42 @@ add_message '[subject]="body search (phrase)"' '[date]="Sat, 01 Jan 2000 12:00:0 add_message '[subject]="negative result"' '[date]="Sat, 01 Jan 2000 12:00:00 -"' '[body]="This phrase should not match the body search"' execute_expecting "search '\"body search (phrase)\"'" "thread:XXX 2000-01-01 [1/1] Notmuch Test Suite; body search (phrase) (inbox unread)" +printf " Show message: json...\t\t" +add_message '[subject]="json-show-subject"' '[date]="Sat, 01 Jan 2000 12:00:00 -"' '[body]="json-show-message"' +execute_expecting "show --format=json 'json-show-message'" '[[[{"id": "'${gen_msg_id}'", "match": true, "filename": "'${gen_msg_filename}'", "date_unix": 946728000, "date_relative": "2000-01-01", "tags": ["inbox","unread"], "headers": {"Subject": "json-show-subject", "From": "Notmuch Test Suite ", "To": "Notmuch Test Suite ", "Cc": "", "Bcc": "", "Date": "Sat, 01 Jan 2000 12:00:00 -"}, "body": [{"id": 1, "content-type": "text/plain", "content": "json-show-message\n"}]}, [' + +printf " Search message: json...\t" +add_message '[subject]="json-search-subject"' '[date]="Sat, 01 Jan 2000 12:00:00 -"' '[body]="json-search-message"' +execute_expecting "search --format=json 'json-search-message'" '[{"thread": "XXX", +"timestamp": 946724400, +"matched": 1, +"total": 1, +"authors": "Notmuch Test Suite", +"subject": "json-search-subject", +"tags": ["inbox", "unread"]}]' + +printf " Search by subject (utf-8):...\t" +add_message [subject]=utf8-sübjéct '[date]="Sat, 01 Jan 2000 12:00:00 -"' +execute_expecting "search subject:utf8-sübjéct" "thread:XXX 2000-01-01 [1/1] Notmuch Test Suite; utf8-sübjéct (inbox unread)" + +printf " Search body (utf-8):...\t" +add_message '[subject]="utf8-message-body-subject"' '[date]="Sat, 01 Jan 2000 12:00:00 -"' '[body]="message body utf8: bödý"' +execute_expecting "search 'bödý'" "thread:XXX 2000-01-01 [1/1] Notmuch Test Suite; utf8-message-body-subject (inbox unread)" + +printf " Show message: json, utf-8...\t" +add_message '[subject]="json-show-utf8-body-sübjéct"' '[date]="Sat, 01 Jan 2000 12:00:00 -"' '[body]="jsön-show-méssage"' +execute_expecting "show --format=json 'jsön-show-méssage'" '[[[{"id": "'${gen_msg_id}'", "match": true, "filename": "'${gen_msg_filename}'", "date_unix": 946728000, "date_relative": "2000-01-01", "tags": ["inbox","unread"], "headers": {"Subject": "json-show-utf8-body-sübjéct", "From": "Notmuch Test Suite ", "To": "Notmuch Test Suite ", "Cc": "", "Bcc": "", "Date": "Sat, 01 Jan 2000 12:00:00 -"}, "body": [{"id": 1, "content-type": "text/plain", "content": "jsön-show-méssage\n"}]}, [' + +printf " Search message: json, utf-8...\t" +add_message '[subject]="json-search-utf8-body-sübjéct"' '[date]="Sat, 01 Jan 2000 12:00:00 -"' '[body]="jsön-search-méssage"' +execute_expecting "search --format=json 'jsön-search-méssage'" '[{"thread": "XXX", +"timestamp": 946724400, +"matched": 1, +"total": 1, +"authors": "Notmuch Test Suite", +"subject": "json-search-utf8-body-sübjéct", +"tags": ["inbox", "unread"]}]' + printf " Search by from: (address)...\t" add_message '[subject]="search by from (address)"' '[date]="Sat, 01 Jan 2000 12:00:00 -"' [from]=searchbyf...@example.com execute_expecting "search from:searchbyf...@example.com" "thread:XXX 2000-01-01 [1/1] searchbyf...@example.com; search by from (address) (inbox unread)" ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Decode headers in reply
On Wed, 3 Mar 2010 08:50:56 +0100, Michal Sojka wrote: > When headers contain non-ASCII characters, they are encoded according > to rfc2047. Nomtuch reply command emits the headers in the encoded > form, which makes them hard to read by humans who compose the reply. This feature is obviously extremely handy. So thank you, Michal! I've now pushed this out. I think the implementation is over-complicated, but that's almost entirely the fault of GMime and GObject, not yours. We are creating a GMime object to represent the message and then asking GMime to print it. GMime then does what it should (assuming the message is going to be sent over SMTP) and encodes the headers. We don't happen to want this encoding, since the client wants to allow the user to edit the message and only encode the final result. There is a single function that GMime provides for the decoding (g_mime_utils_header_decode_text) but arranging for GMime to call this function on each header requires over 200 lines of code with the hideous GObject boilerplate and a bunch of replicated parsing code. Meanwhile, what's GMime actually doing for us here? We have the original decoded strings in the first place. And we know how to print "Subject:", "To:", and "From:". So what do we need GMime for the headers? The only thing I can think of is that GMime is also inserting RFC-compliant wrapping of long lines. But since we want to let the user edit the subject, etc. anyway, don't we have to rely on the client to do that *anyway*? Incidentally, it looks like message-mode does have support to do RCF-compliant line wrapping if I hit M-q (`fill-paragraph') on a long Subject: line but it doesn't appear to do that automatically. Instead, it will just send a non-RFC-compliant message if I just type a long Subject line. That looks like yet another reason to have a notmuch-message-mode that extends message-mode and fixes several issues we've been identifying. Back to the patch though, I have pushed this out, but I've also added a TODO item for simplifying this stuff. I think a handful of calls to printf would be much better than this big pile of GObject boilerplate and ad-hoc parsing. -Carl pgpMAf0jrxoy0.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Plans for the 0.2 release (this week)
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: > > * Any further changes from the Sebastian's repository. Sebastian, I > worked through one list I saw recently. Do you have another list to > propose yet? Sebastian sent a list of these, and they are merged now. > * The big batch of emacs-client improvements from David E.'s > repository. David, do you have particular things to recommend > here? David has no followed up with a rebase of his entire branch. It looks *very* nice still but won't be in 0.2. I plan to land this early and make it the focus of the 0.3 release. > * Changes to indexing, (addition of body:, folder:, list:, etc.). This > is stuff that I'll work on. I haven't gotten to this yet. It's a big change, (in that it requires everyone to rebuild their database). So this will need some careful testing. And I'd like to get as many changes in at once so we won't all have to rebuild are databases in the following release. This stuff will be the focus of the 0.4 release. > * Some library additions (move_to_first for the iterators, and perhaps > a notmuch_database_add_message_with_data which Srinivasa requested > to support integration of notmuch into evolution). I'll work on > these as well, (I know that there are patches for some of these on > the list already). I'll take a look at the existing patches for the iterators. That's still 0.2 material. The add_message_with_data feature will come later. > * Anything else that people want, (especially things that already > exist and that you're already using). Thanks for several suggestions in reply to this message. I think they are all merged now. Let me know if I missed anything. -Carl pgpEWe14gGOy2.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Fix code extracting the MTA from Received: headers
On Thu, 08 Apr 2010 08:07:48 -0700, Dirk Hohndel wrote: > Right now my plan is to do something like this: > > 1) look for my email address in To/Cc > 2) look for my email in "for " in Received headers > 3) look for my email in X-Original-To > 4) look for the domain of my email in Received headers (not just 1st) > 5) punt and use default email address > > Does that sound sane? It sounds sane. > (and thanks for sending the headers - this really helps... can others > for whom the current code or the logic mentioned above wouldn't work > send their headers, too, please?) I started using fetchmail many years ago and have never really needed to switch. So I'm still using that, (but don't necessarily recommend it to anyone. It seems to break the above since it delivers mail locally, so the first headers I get are: X-Original-To: cwo...@localhost Delivered-To: cwo...@localhost Received: from yoom.home.cworth.org (yoom.home.cworth.org [127.0.0.1]) by yoom.home.cworth.org (Postfix) with ESMTP id D391B5883A6 for ; Mon, 12 Apr 2010 09:11:18 -0700 (PDT) MIME-Version: 1.0 Received: from 10.22.226.213 [10.22.226.213] by yoom.home.cworth.org with IMAP (fetchmail-6.3.16) for (single-drop); Mon, 12 Apr 2010 09:11:18 -0700 (PDT) And none of these are useful for your detection. Worse, the presence of "cworth.org" in the above might throw your detection off before it could find something useful like "intel.com" in a later Received header. I'll send a complete message with full headers to you separately. Perhaps I can just switch programs to transfer email and avoid this problem. Anyone have a recommendation for something to transfer mail From an imap server to the local matchine, (but *not* leaving it stored on the imap server)[*]. I don't think offlineimap supports this mode does it? -Carl [*] I do separately want to start playing with remote notmuch, but I won't use this with the imap servers currently accepting my mail. Instead, I'd rather just rsync my mail from my local machine to a server I own, (which could then export imap if needed), and do remote notmuch stuff from there. pgp4Og6GZRwoM.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] RFC: User-Agent header
On Mon, 12 Apr 2010 10:30:54 +0200, "Sebastian Spaeth" wrote: > > OK, final post from me on this issue. No, wait! I want more from you. :-) Would you care to put together a solution that does this from within notmuch*.el ? I really want things usable by default without people having to hack up their .emacs files. Of course, we could also easily add a variable to make this not happen, (but that can be added in a follow-on patch by anyone). Thanks, -Carl pgpSMRw949mzF.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/4] Mailstore abstraction interface
On Thu, 8 Apr 2010 16:42:43 +0200, Michal Sojka wrote: > The goal of mailstore abstraction is to allow notmuch to store tags > together with email messages. The abstract interface is needed because > people want to use different ways of storing their emails. Currently, > there exists implementation for two types of mailstore - plain files > and maildir. It is expected that additional git-based mailstore will > be developed later. I don't agree with the approach being taken here. I don't think that the expectation of future need is a good basis for adding a level of abstraction now. This gives us current costs without benefit. Meanwhile, the two different mail stores that you are currently support ("plain" and "maildir") aren't really different types. We do already have code within notmuch to detect whether any particular directory is a maildir, (with the heuristic of looking for child directories named "cur", "new", and "tmp"). So I think we can and should support both maildir and non-maildir mail storage just fine. The question of "once you have maildir storage, should you synchronize that tags" is quite separate. The answer there might be "yes", "no", or "let the user decide". But if it is configurable, then the configuration should be something like [maildir] synchronize_flags=yes rather than [mailstore] type=maildir This series is looking like one of the most complete approaches to maildir-flag synchronization, (and I like some of the motivation that leads to "notmuch cat"). But I think the mailstore abstraction is largely a distraction from the real features here. -Carl pgpc5AOWkZDdr.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH v2] notmuch.el: add functionality in notmuch search mode to add or remove tags by region
On Fri, 09 Apr 2010 10:11:00 -0400, Jesse Rosenthal wrote: > I'll play with both and see which is clearer. Any progress here, Jesse? I'd like to release notmuch 0.2 soon and would prefer not to revert this feature, (but I also don't really want to ship it with this known bug). -Carl pgpL8LvhAU0Cn.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH v2] notmuch.el: add functionality in notmuch search mode to add or remove tags by region
Sorry -- just got back into town from some business travel. I'll be working on it this afternoon, and will let you know by this evening where I get with it. Best, Jesse On Tue, 13 Apr 2010 10:55:55 -0700, Carl Worth wrote: > On Fri, 09 Apr 2010 10:11:00 -0400, Jesse Rosenthal > wrote: > > I'll play with both and see which is clearer. > > Any progress here, Jesse? > > I'd like to release notmuch 0.2 soon and would prefer not to revert this > feature, (but I also don't really want to ship it with this known bug). > > -Carl Non-text part: application/pgp-signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
An update on 0.2 progress
I just wanted to let everyone know that I think the code for the 0.2 release of notmuch is pretty much in place now. I've either merged or decided to postpone most all of the proposed features. I'll follow-up with another mail giving the detailed list of features that have been merged or postponed, and I'd like to release 0.2 by the end of the day today. In the meantime, here are 3 small things still left: * Investigate patches to add the move_to_first iterator improvements * Revert support for "*" as a search term. I threw this in while merging the support for "notmuch count" with no arguments, but it's quite broken currently, (scrambled dates in output of "notmuch search *" output, broken support for filtering a "*" search in the emacs code). * Perhaps revert the region-based tag feature in the notmuch interface. This has a bug leading to a very confusing failure mode when the region includes the last line of the buffer. I'd prefer to see a fix before 0.2, but I could revert this feature instead. Thanks for all the work going in already. There's a bunch of good stuff here, (and some stuff I was sad to see not make the cut---but that gives us something to look forward to next week!). -Carl pgpJB1NL4MpLV.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Fix code extracting the MTA from Received: headers
On Tue, 13 Apr 2010 10:37:49 -0700, Carl Worth wrote: > On Thu, 08 Apr 2010 08:07:48 -0700, Dirk Hohndel > wrote: > > Right now my plan is to do something like this: > > > > 1) look for my email address in To/Cc > > 2) look for my email in "for " in Received headers > > 3) look for my email in X-Original-To > > 4) look for the domain of my email in Received headers (not just 1st) > > 5) punt and use default email address > > > > Does that sound sane? > > It sounds sane. Good. > > (and thanks for sending the headers - this really helps... can others > > for whom the current code or the logic mentioned above wouldn't work > > send their headers, too, please?) > > I started using fetchmail many years ago and have never really needed to > switch. So I'm still using that, (but don't necessarily recommend it to > anyone. > > It seems to break the above since it delivers mail locally, so the first > headers I get are: > > X-Original-To: cwo...@localhost Easy to detect. I'll add that as an exclusion > Delivered-To: cwo...@localhost > Received: from yoom.home.cworth.org (yoom.home.cworth.org [127.0.0.1]) > by yoom.home.cworth.org (Postfix) with ESMTP id D391B5883A6 > for ; Mon, 12 Apr 2010 09:11:18 -0700 (PDT) > MIME-Version: 1.0 > Received: from 10.22.226.213 [10.22.226.213] > by yoom.home.cworth.org with IMAP (fetchmail-6.3.16) > for (single-drop); Mon, 12 Apr 2010 09:11:18 > -0700 (PDT) A (he runs screaming out of the room) > And none of these are useful for your detection. Worse, the presence of > "cworth.org" in the above might throw your detection off before it could > find something useful like "intel.com" in a later Received header. I have some choice words for these headers... And an idea how to exclude these false positives as well... It's kind of a hack, but I'm thinking that in order for the "Received: ... by ..." part to be truly relevant to us, the from host should have a non-private IP address. Yes, I can envision within-your-own-network cases where none of the systems have a non-private email address... but then hopefully your last hop is correct... if not - your setup is even more screwed up than Carl's. > I'll send a complete message with full headers to you separately. Thanks > Perhaps I can just switch programs to transfer email and avoid this > problem. Anyone have a recommendation for something to transfer mail > From an imap server to the local matchine, (but *not* leaving it stored > on the imap server)[*]. I don't think offlineimap supports this mode > does it? Don't think so. I'm not going to comment on the usefulness of this mode in public :-) /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Add strcasestr v.3 - add compat implementation of strcasestr
v.3 of this patch, now with the changes to makefiles, configure script compat.h and all new files that I need Please test on platforms lacking strcasestr Signed-off-by: Dirk Hohndel --- compat/Makefile.local|4 compat/compat.h |4 compat/have_strcasestr.c | 10 ++ compat/strcasestr.c | 41 + configure| 20 ++-- 5 files changed, 77 insertions(+), 2 deletions(-) create mode 100644 compat/have_strcasestr.c create mode 100644 compat/strcasestr.c diff --git a/compat/Makefile.local b/compat/Makefile.local index 81e6c70..2a17309 100644 --- a/compat/Makefile.local +++ b/compat/Makefile.local @@ -8,3 +8,7 @@ notmuch_compat_srcs = ifneq ($(HAVE_GETLINE),1) notmuch_compat_srcs += $(dir)/getline.c $(dir)/getdelim.c endif + +ifneq ($(HAVE_STRCASESTR),1) +notmuch_compat_srcs += $(dir)/strcasestr.c +endif diff --git a/compat/compat.h b/compat/compat.h index d639e0f..173ef68 100644 --- a/compat/compat.h +++ b/compat/compat.h @@ -38,4 +38,8 @@ getdelim (char **lineptr, size_t *n, int delimiter, FILE *fp); #endif /* !HAVE_GETLINE */ +#if !HAVE_STRCASESTR +char* strcasestr(const char *haystack, const char *needle); +#endif /* !HAVE_STRCASESTR */ + #endif /* NOTMUCH_COMPAT_H */ diff --git a/compat/have_strcasestr.c b/compat/have_strcasestr.c new file mode 100644 index 000..c0fb762 --- /dev/null +++ b/compat/have_strcasestr.c @@ -0,0 +1,10 @@ +#define _GNU_SOURCE +#include + +int main() +{ +char *found; +const char *haystack, *needle; + +found = strcasestr(haystack, needle); +} diff --git a/compat/strcasestr.c b/compat/strcasestr.c new file mode 100644 index 000..50bc89d --- /dev/null +++ b/compat/strcasestr.c @@ -0,0 +1,41 @@ +/* + * slow simplistic reimplementation of strcasestr for systems that + * don't include it in their library + * + * based on a GPL implementation in OpenTTD found under GPL v2 + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation, version 2. + + This program is distributed in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA + 02110-1301, USA. */ + +/* Imported into notmuch by Dirk Hohndel - original author unknown. */ +/* the semantic here actually puzzles me: + how can haystack be const char * - yet the return value is char * + after all, it points to a sub-string of haystack... */ + +#include + +char *strcasestr(const char *haystack, const char *needle) +{ + size_t hay_len = strlen(haystack); + size_t needle_len = strlen(needle); + while (hay_len >= needle_len) { + if (strncasecmp(haystack, needle, needle_len) == 0) + return (char *) haystack; + + haystack++; + hay_len--; + } + + return NULL; +} diff --git a/configure b/configure index 5af7852..90a399c 100755 --- a/configure +++ b/configure @@ -310,6 +310,17 @@ else fi rm -f compat/have_getline +printf "Checking for strcasestr... " +if ${CC} -o compat/have_strcasestr compat/have_strcasestr.c > /dev/null 2>&1 +then +printf "Yes.\n" +have_strcasestr=1 +else +printf "No (will use our own instead).\n" +have_strcasestr=0 +fi +rm -f compat/have_strcasestr + cat
[PATCH] Add simplistic compat implementation for strcasestr
v.2 of the patch, this time including the Makefile logic. All platforms I have access to support strcasestr - so please test that the implementation / integration works correctly on those plattforms. Signed-off-by: Dirk Hohndel --- compat/have_strcasestr.c | 10 ++ compat/strcasestr.c | 41 + 2 files changed, 51 insertions(+), 0 deletions(-) create mode 100644 compat/have_strcasestr.c create mode 100644 compat/strcasestr.c diff --git a/compat/have_strcasestr.c b/compat/have_strcasestr.c new file mode 100644 index 000..c0fb762 --- /dev/null +++ b/compat/have_strcasestr.c @@ -0,0 +1,10 @@ +#define _GNU_SOURCE +#include + +int main() +{ +char *found; +const char *haystack, *needle; + +found = strcasestr(haystack, needle); +} diff --git a/compat/strcasestr.c b/compat/strcasestr.c new file mode 100644 index 000..50bc89d --- /dev/null +++ b/compat/strcasestr.c @@ -0,0 +1,41 @@ +/* + * slow simplistic reimplementation of strcasestr for systems that + * don't include it in their library + * + * based on a GPL implementation in OpenTTD found under GPL v2 + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation, version 2. + + This program is distributed in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA + 02110-1301, USA. */ + +/* Imported into notmuch by Dirk Hohndel - original author unknown. */ +/* the semantic here actually puzzles me: + how can haystack be const char * - yet the return value is char * + after all, it points to a sub-string of haystack... */ + +#include + +char *strcasestr(const char *haystack, const char *needle) +{ + size_t hay_len = strlen(haystack); + size_t needle_len = strlen(needle); + while (hay_len >= needle_len) { + if (strncasecmp(haystack, needle, needle_len) == 0) + return (char *) haystack; + + haystack++; + hay_len--; + } + + return NULL; +} -- 1.6.6.1 -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Add strcasestr v.3 - add compat implementation of strcasestr
On 4/13/10 6:47 PM, Dirk Hohndel wrote: v.3 of this patch, now with the changes to makefiles, configure script compat.h and all new files that I need Please test on platforms lacking strcasestr Signed-off-by: Dirk Hohndel Tested-by: Tomas Carnecky (on OpenSolaris snv_134) tom ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Fix bug, and clean up code duplication, in adding or removing tag by region.
There was a bug in notmuch-search-{add,remove}-tag-region, which would not behave correctly if the region went beyond the last message. Now, instead of simply iterating to the last line of the region, these functions will iterate to the minimum of the last line of the region and the last possible line, i.e. (- (line-number-at-pos (point-max)) 2) Also clean up code duplication, as per Carl's suggestion, by making notmuch-search-{add/remove}-tag-thread a special case of the -region commands, where the region in question is between (point) and (point). --- emacs/notmuch.el | 26 ++ 1 files changed, 14 insertions(+), 12 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 517c53a..be09f42 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -399,10 +399,11 @@ Complete list of currently available key bindings: (defun notmuch-search-properties-in-region (property beg end) (save-excursion (let ((output nil) - (last-line (line-number-at-pos end))) + (last-line (line-number-at-pos end)) + (max-line (- (line-number-at-pos (point-max)) 2))) (goto-char beg) (beginning-of-line) - (while (<= (line-number-at-pos) last-line) + (while (<= (line-number-at-pos) (min last-line max-line)) (setq output (cons (get-text-property (point) property) output)) (forward-line 1)) output))) @@ -497,38 +498,39 @@ and will also appear in a buffer named \"*Notmuch errors*\"." (defun notmuch-search-get-tags-region (beg end) (save-excursion (let ((output nil) - (last-line (line-number-at-pos end))) + (last-line (line-number-at-pos end)) + (max-line (- (line-number-at-pos (point-max)) 2))) (goto-char beg) - (while (<= (line-number-at-pos) last-line) + (while (<= (line-number-at-pos) (min last-line max-line)) (setq output (append output (notmuch-search-get-tags))) (forward-line 1)) output))) (defun notmuch-search-add-tag-thread (tag) - (notmuch-call-notmuch-process "tag" (concat "+" tag) (notmuch-search-find-thread-id)) - (notmuch-search-set-tags (delete-dups (sort (cons tag (notmuch-search-get-tags)) 'string< + (notmuch-search-add-tag-region tag (point) (point))) (defun notmuch-search-add-tag-region (tag beg end) (let ((search-id-string (mapconcat 'identity (notmuch-search-find-thread-id-region beg end) " or "))) (notmuch-call-notmuch-process "tag" (concat "+" tag) search-id-string) (save-excursion - (let ((last-line (line-number-at-pos end))) + (let ((last-line (line-number-at-pos end)) + (max-line (- (line-number-at-pos (point-max)) 2))) (goto-char beg) - (while (<= (line-number-at-pos) last-line) + (while (<= (line-number-at-pos) (min last-line max-line)) (notmuch-search-set-tags (delete-dups (sort (cons tag (notmuch-search-get-tags)) 'string<))) (forward-line)) (defun notmuch-search-remove-tag-thread (tag) - (notmuch-call-notmuch-process "tag" (concat "-" tag) (notmuch-search-find-thread-id)) - (notmuch-search-set-tags (delete tag (notmuch-search-get-tags + (notmuch-search-remove-tag-region tag (point) (point))) (defun notmuch-search-remove-tag-region (tag beg end) (let ((search-id-string (mapconcat 'identity (notmuch-search-find-thread-id-region beg end) " or "))) (notmuch-call-notmuch-process "tag" (concat "-" tag) search-id-string) (save-excursion - (let ((last-line (line-number-at-pos end))) + (let ((last-line (line-number-at-pos end)) + (max-line (- (line-number-at-pos (point-max)) 2))) (goto-char beg) - (while (<= (line-number-at-pos) last-line) + (while (<= (line-number-at-pos) (min last-line max-line)) (notmuch-search-set-tags (delete tag (notmuch-search-get-tags))) (forward-line)) -- 1.6.5.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Use wrapper functions to find the type of struct dirent
Some platforms don't provide DT_REG/DT_LNK/DT_DIR. Create wrapper functions which test the presence of those symbols and fall back to stat(2). --- Not sure if I got the handling of DT_UNKNOWN correct in all cases. Someone please double-check that. notmuch-new.c | 70 ++-- 1 files changed, 62 insertions(+), 8 deletions(-) diff --git a/notmuch-new.c b/notmuch-new.c index 44b50aa..95b 100644 --- a/notmuch-new.c +++ b/notmuch-new.c @@ -140,6 +140,62 @@ dirent_sort_strcmp_name (const struct dirent **a, const struct dirent **b) return strcmp ((*a)->d_name, (*b)->d_name); } +/* Helper functions to test if a given dirent is of a certain type + */ +static int +_is_reg(const char *path, struct dirent *entry) +{ +#ifdef DT_REG +if (entry->d_type == DT_REG) +return 1; +#endif + +char buffer[PATH_MAX]; +snprintf(buffer, PATH_MAX, "%s/%s", path, entry->d_name); + +struct stat sbuf; +if (!stat(buffer, &sbuf)) +return S_ISREG(sbuf.st_mode); + +return 0; +} + +static int +_is_dir(const char *path, struct dirent *entry) +{ +#ifdef DT_DIR +if (entry->d_type == DT_DIR) +return 1; +#endif + +char buffer[PATH_MAX]; +snprintf(buffer, PATH_MAX, "%s/%s", path, entry->d_name); + +struct stat sbuf; +if (!stat(buffer, &sbuf)) +return S_ISDIR(sbuf.st_mode); + +return 0; +} + +static int +_is_lnk(const char *path, struct dirent *entry) +{ +#ifdef DT_LNK +if (entry->d_type == DT_LNK) +return 1; +#endif + +char buffer[PATH_MAX]; +snprintf(buffer, PATH_MAX, "%s/%s", path, entry->d_name); + +struct stat sbuf; +if (!stat(buffer, &sbuf)) +return S_ISLNK(sbuf.st_mode); + +return 0; +} + /* Test if the directory looks like a Maildir directory. * * Search through the array of directory entries to see if we can find all @@ -148,12 +204,12 @@ dirent_sort_strcmp_name (const struct dirent **a, const struct dirent **b) * Return 1 if the directory looks like a Maildir and 0 otherwise. */ static int -_entries_resemble_maildir (struct dirent **entries, int count) +_entries_resemble_maildir (const char *path, struct dirent **entries, int count) { int i, found = 0; for (i = 0; i < count; i++) { - if (entries[i]->d_type != DT_DIR && entries[i]->d_type != DT_UNKNOWN) + if (!_is_dir(path, entries[i])) continue; if (strcmp(entries[i]->d_name, "new") == 0 || @@ -265,7 +321,7 @@ add_files_recursive (notmuch_database_t *notmuch, } /* Pass 1: Recurse into all sub-directories. */ -is_maildir = _entries_resemble_maildir (fs_entries, num_fs_entries); +is_maildir = _entries_resemble_maildir (path, fs_entries, num_fs_entries); for (i = 0; i < num_fs_entries; i++) { if (interrupted) @@ -280,9 +336,7 @@ add_files_recursive (notmuch_database_t *notmuch, * scandir results, then it might be a directory (and if not, * then we'll stat and return immediately in the next level of * recursion). */ - if (entry->d_type != DT_DIR && - entry->d_type != DT_LNK && - entry->d_type != DT_UNKNOWN) + if (!_is_dir(path, entry) && !_is_lnk(path, entry)) { continue; } @@ -360,7 +414,7 @@ add_files_recursive (notmuch_database_t *notmuch, * * In either case, a stat does the trick. */ - if (entry->d_type == DT_LNK || entry->d_type == DT_UNKNOWN) { + if (_is_lnk(path, entry)) { int err; next = talloc_asprintf (notmuch, "%s/%s", path, entry->d_name); @@ -376,7 +430,7 @@ add_files_recursive (notmuch_database_t *notmuch, if (! S_ISREG (st.st_mode)) continue; - } else if (entry->d_type != DT_REG) { + } else if (!_is_reg(path, entry)) { continue; } -- 1.7.0.5 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Add strcasestr v.3 - add compat implementation of strcasestr
On Tue, 13 Apr 2010 20:47:02 +0200, Tomas Carnecky wrote: > On 4/13/10 6:47 PM, Dirk Hohndel wrote: > > > > v.3 of this patch, now with the changes to makefiles, configure script > > compat.h and all new files that I need > > Please test on platforms lacking strcasestr > > > > Signed-off-by: Dirk Hohndel > > Tested-by: Tomas Carnecky > > (on OpenSolaris snv_134) Thanks Tomas, I really appreciate it. /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/4] Mailstore abstraction interface
On Tue, 13 Apr 2010 10:53:12 -0700, Carl Worth wrote: > This series is looking like one of the most complete approaches to > maildir-flag synchronization, (and I like some of the motivation that > leads to "notmuch cat"). But I think the mailstore abstraction is > largely a distraction from the real features here. For my case (of wanting to have backup of my mailstore complete in reasonable time, preferably using less disk space) of wanting mail in git packs, 'notmuch cat' being used everywhere removes a lot of the issues of doing this. (pluggin in an alternative to readdir is fairly simple... but the emacs UI needs to read from it too :) -- Stewart Smith ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
See only unread message in a thread ?
Hi, maybe I missread the "manual" but I can't find an easy way to do something simple in notmuch.el. Say I have a thread with A-B-C. I visit the thread and read the whole thread. Let's say after 'notmuch new' a post has entered the thread: A-B-C-D. Is there an easy way to just have one of these behaviour: - only show the new message (with an option to toggle display of the old messages) - display the whole thread with the 3 read messages 'collapsed' and only the unread message 'expanded' Thank you Xavier ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: See only unread message in a thread ?
On Wed, 14 Apr 2010 00:11:50 +0200, Xavier Maillard wrote: > Hi, > > maybe I missread the "manual" but I can't find an easy way to do > something simple in notmuch.el. > > Say I have a thread with A-B-C. I visit the thread and read the > whole thread. Let's say after 'notmuch new' a post has entered > the thread: A-B-C-D. Is there an easy way to just have one of > these behaviour: > > - only show the new message (with an option to toggle display of > the old messages) > - display the whole thread with the 3 read messages 'collapsed' > and only the unread message 'expanded' This is the default behaviour in my experience. Reading a message unsets the 'unread' tag. The default search if for 'inbox' + 'unread'. This lists the threads where any message within matches that criterion. When viewing a thread from there the messages that don't match are collapsed. Therefore if you are remove the 'unread' tag when reading mail you will only read the newest messages when 'notmuch new' adds a new message to the thread if the search that took you there included the 'unread' tag. Thanks, James ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: See only unread message in a thread ?
On Tue, 13 Apr 2010 23:19:37 +0100, James Westby wrote: > On Wed, 14 Apr 2010 00:11:50 +0200, Xavier Maillard wrote: > > Hi, > > > > maybe I missread the "manual" but I can't find an easy way to do > > something simple in notmuch.el. > > > > Say I have a thread with A-B-C. I visit the thread and read the > > whole thread. Let's say after 'notmuch new' a post has entered > > the thread: A-B-C-D. Is there an easy way to just have one of > > these behaviour: > > > > - only show the new message (with an option to toggle display of > > the old messages) > > - display the whole thread with the 3 read messages 'collapsed' > > and only the unread message 'expanded' > > This is the default behaviour in my experience. > > Reading a message unsets the 'unread' tag. Is it done automatically ? Or do I need to do something special in order to unset the unread tag ? I see there is 'a' and 'x' when in notmuch-show but I am not sure I have to explicitely press on of these keys. Currently, when in a notmuch-search buffer, I press RET to visit the thread and then I play with 'n' to go next message till I read the whole thread. Then, I press 'q' to go back to the notmuch-search buffer. Is this the way to do ? Thank you Xavier ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] RFC: User-Agent header
On Tue, 13 Apr 2010 10:44:03 -0700, Carl Worth wrote: > On Mon, 12 Apr 2010 10:30:54 +0200, "Sebastian Spaeth" > wrote: > > > > OK, final post from me on this issue. > > No, wait! I want more from you. :-) > > Would you care to put together a solution that does this from within > notmuch*.el ? I really want things usable by default without people > having to hack up their .emacs files. +1 > Of course, we could also easily add a variable to make this not happen, > (but that can be added in a follow-on patch by anyone). +1 Xavier ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: See only unread message in a thread ?
On Tue, 13 Apr 2010 23:19:37 +0100, James Westby wrote: > On Wed, 14 Apr 2010 00:11:50 +0200, Xavier Maillard wrote: > > Say I have a thread with A-B-C. I visit the thread and read the > > whole thread. Let's say after 'notmuch new' a post has entered > > the thread: A-B-C-D. Is there an easy way to just have one of > > these behaviour: > > > > - only show the new message (with an option to toggle display of > > the old messages) > > - display the whole thread with the 3 read messages 'collapsed' > > and only the unread message 'expanded' > > This is the default behaviour in my experience. I agree this is the behavior I see, but there is a caveat that may be the cause of confusion: > Reading a message unsets the 'unread' tag. > > The default search if for 'inbox' + 'unread'. Actually, the default search is for just "tag:inbox", which will also display any messages in the inbox that have "tag:unread" as well. But remember that if you are coming from a search for "tag:inbox", when you view a thread all the message with "tag:inbox" will be visible (uncollapsed), whether or not they have "tag:unread" not. Just reading a message will not cause it to collapse when coming from a "tag:inbox" search. I think this might be where the confusion is coming from. If you want to view just the messages in your inbox that are unread, then you need to search for "tag:inbox and tag:unread", or type 'f' in notmuch mode to filter your inbox search with the "tag:unread" search. Make sense? jamie. pgpAYHO1fA5YM.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] allow to not sort the search results
previously we were always sorting the returned results by some string value, but sometimes we might just be interested in the number of results, and don't need any sorting. Also add a --sort=unsorted command line option to notmuch search to test this. A search that matches 1200 messages, returns in default sort in 0.982 seconds and unsorted in 0.978 seconds with very little variance (with a warm cache). Xapian contributor Olly Betts says that the speed gains for a cold cache are likely to be much higher though. Signed-off-by: Sebastian Spaeth --- lib/notmuch.h|3 ++- lib/query.cc |2 ++ notmuch-search.c |2 ++ 3 files changed, 6 insertions(+), 1 deletions(-) diff --git a/lib/notmuch.h b/lib/notmuch.h index a7e66dd..bae48a6 100644 --- a/lib/notmuch.h +++ b/lib/notmuch.h @@ -346,7 +346,8 @@ notmuch_query_create (notmuch_database_t *database, typedef enum { NOTMUCH_SORT_OLDEST_FIRST, NOTMUCH_SORT_NEWEST_FIRST, -NOTMUCH_SORT_MESSAGE_ID +NOTMUCH_SORT_MESSAGE_ID, +NOTMUCH_SORT_UNSORTED } notmuch_sort_t; /* Specify the sorting desired for this query. */ diff --git a/lib/query.cc b/lib/query.cc index 10f8dc8..4148f9b 100644 --- a/lib/query.cc +++ b/lib/query.cc @@ -148,6 +148,8 @@ notmuch_query_search_messages (notmuch_query_t *query) case NOTMUCH_SORT_MESSAGE_ID: enquire.set_sort_by_value (NOTMUCH_VALUE_MESSAGE_ID, FALSE); break; +case NOTMUCH_SORT_UNSORTED: + break; } #if DEBUG_QUERY diff --git a/notmuch-search.c b/notmuch-search.c index 4e3514b..854a9ae 100644 --- a/notmuch-search.c +++ b/notmuch-search.c @@ -217,6 +217,8 @@ notmuch_search_command (void *ctx, int argc, char *argv[]) sort = NOTMUCH_SORT_OLDEST_FIRST; } else if (strcmp (opt, "newest-first") == 0) { sort = NOTMUCH_SORT_NEWEST_FIRST; + } else if (strcmp (opt, "unsorted") == 0) { + sort = NOTMUCH_SORT_UNSORTED; } else { fprintf (stderr, "Invalid value for --sort: %s\n", opt); return 1; -- 1.6.3.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] allow to not sort the search results
Sebastian Spaeth wrote: > previously we were always sorting the returned results by some string value, > but sometimes we might just be interested in the number of results, and don't > need any sorting. > > Also add a --sort=unsorted command line option to notmuch search to test this. Does this provide relevance-ranked search results? I think relevance ranking is the Xapian default if a sort order isn't specified. It would be useful to be able to obtain a relevance-ranked list of messages or threads that satisfy a query. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] notmuch new --new-tags=tags...
On Tue, Apr 13, 2010 at 01:55, Jameson Rollins wrote: > On Mon, 12 Apr 2010 17:11:24 +0200, Michal Sojka > wrote: >> The problem I see with this approach is, that all notmuch searches are >> build around Xapian. ... > This does sound like a potential issue. ?I definitely don't understand > how new messages are added to the database. ?I was mostly suggesting a > syntax for adding tag as new messages are added, though, not that an > actual xapian search term. ?I don't know if they can be decoupled, > though. If you say "they're just notmuch tag commands applied at new time" you expect to have the same search behaviour as Xapian... Maybe you could do that by temporarily inserting the mail into an "inmemory" Xapian database, since you're only checking to see if that particular one matches. On the other hand, maybe having it be a separate syntax would be good -- then you could justify using information notmuch doesn't usually have -- like file/path names, Received or Delivered-To headers, and so on. On the gripping hand, maybe "notmuch tag" should simply be fast enough that running a bunch of them after "notmuch new" isn't an issue. Cheers, aj -- Anthony Towns
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 portability., 2010-02-04). TC> Is strcasestr really necessary there or can it be replaced with strstr? strcasecmp is POSIX.1-2001. If you know any OS which does not have it, add a new file to compat/ subdir. -- http://fossarchy.blogspot.com/ -- 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/20100413/dd30ea39/attachment.pgp>
Use of strcasestr
On 4/12/10 10:18 PM, Mikhail Gusarov wrote: > > 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 portability., 2010-02-04). > > TC> Is strcasestr really necessary there or can it be replaced with strstr? > > strcasecmp is POSIX.1-2001. Indeed it is, but the code uses strcasestr and I couldn't find any indication which standard that function is part of. Adding that function to compat/ probably is the way to go, but the whole compat mechanism doesn't work here. It's like if compat/Makefile.local was not included in the top-level makefile, notmuch_compat_srcs is empty there. Any ideas how to debug that? tom
[PATCH] Add compat version of strcasestr
strcasestr is not part of any standard (unlike for example strcasecmp) and thus not available on all platforms (in my case Solaris). --- compat/Makefile.local|4 compat/compat.h |4 compat/have_strcasestr.c |8 compat/strcasestr.c | 15 +++ configure| 19 +-- 5 files changed, 48 insertions(+), 2 deletions(-) create mode 100644 compat/have_strcasestr.c create mode 100644 compat/strcasestr.c diff --git a/compat/Makefile.local b/compat/Makefile.local index 81e6c70..328eca2 100644 --- a/compat/Makefile.local +++ b/compat/Makefile.local @@ -8,3 +8,7 @@ notmuch_compat_srcs = ifneq ($(HAVE_GETLINE),1) notmuch_compat_srcs += $(dir)/getline.c $(dir)/getdelim.c endif + +ifneq ($(HAVE_STRCASESTR),1) +notmuch_compat_srcs += $(dir)/strcasestr.c +endif diff --git a/compat/compat.h b/compat/compat.h index d639e0f..be70bd8 100644 --- a/compat/compat.h +++ b/compat/compat.h @@ -38,4 +38,8 @@ getdelim (char **lineptr, size_t *n, int delimiter, FILE *fp); #endif /* !HAVE_GETLINE */ +#if !HAVE_STRCASESTR +char *strcasestr(char *a, char *b); +#endif /* !HAVE_STRCASESTR */ + #endif /* NOTMUCH_COMPAT_H */ diff --git a/compat/have_strcasestr.c b/compat/have_strcasestr.c new file mode 100644 index 000..36e760d --- /dev/null +++ b/compat/have_strcasestr.c @@ -0,0 +1,8 @@ + +#include +#include + +int main() +{ + return strcasestr("",""); +} diff --git a/compat/strcasestr.c b/compat/strcasestr.c new file mode 100644 index 000..a4188b9 --- /dev/null +++ b/compat/strcasestr.c @@ -0,0 +1,15 @@ + +#include +#include + +char *strcasestr(char *a, char *b) +{ + size_t l; + char f[3]; + + snprintf(f, sizeof(f), "%c%c", tolower(*b), toupper(*b)); + for (l = strcspn(a, f); l != strlen(a); l += strcspn(a + l + 1, f) + 1) +if (strncasecmp(a + l, b, strlen(b)) == 0) + return a + l; + return NULL; +} diff --git a/configure b/configure index 5af7852..add2da6 100755 --- a/configure +++ b/configure @@ -310,6 +310,17 @@ else fi rm -f compat/have_getline +printf "Checking for strcasestr... " +if ${CC} -o compat/have_strcasestr compat/have_strcasestr.c > /dev/null 2>&1 +then +printf "Yes.\n" +have_strcasestr=1 +else +printf "No (will use our own instead).\n" +have_strcasestr=0 +fi +rm -f compat/have_strcasestr + cat <
[PATCH] Add simplistic reimplementation of strcasestr to compat library
On 4/13/10 6:10 AM, Dirk Hohndel wrote: > > While all systems that I have access to support strcasestr, it is > in fact not part of POSIX. So here's a fallback reimplementation > based on POSIX functions. Your patch is missing the part where it adds -DHAVE_STRCASESTR=.. to CONFIGURE_C{XX,}FLAGS. And I still have to figure out the licencing of my patch (need to wait for the original author to respond). So maybe your patch, with the missing parts added, is better. tom
[PATCH] emacs: Add notmuch-hello.el, a friendly frontend to notmuch
On Mon, 12 Apr 2010 11:13:30 +0100, David Edmondson wrote: > commit e55dc251b9e8001fe16873fadac565563e606d69 > Author: David Edmondson > Date: Mon Apr 12 11:12:23 2010 +0100 > > emacs: Add notmuch-hello.el, a friendly frontend to notmuch I like it ! Xavier
[PATCH] Add simplistic reimplementation of strcasestr to compat library
On Tue, Apr 13, 2010 at 14:10, Dirk Hohndel wrote: > +/* the semantic here actually puzzles me: > + ? how can haystack be const char * - yet the return value is char * > + ? after all, it points to a sub-string of haystack... */ Dunno if this is a question from the original source, but the answer if anyone's interested is probably because C doesn't have templates -- you'd ideally like to have it treated as: char *strcasestr(char *haystack, const char *needle); for when you're doing a search and replace on the needle (say), and: const char *strcasestr(const char *haystack, const char *needle); for when you're doing a search for the needle in something you can't modify. But C isn't clever enough to let you say that with just one function (and no fancy #defines), so you have to drop some of the typechecking with the (char*) cast on the return value if you want to handle both use cases, without the compiler complaining about const->non-const conversions in otherwise correct code in one case or the other. Cheers, aj -- Anthony Towns
[PATCH] emacs: Add notmuch-hello.el, a friendly frontend to notmuch
On Tue, 13 Apr 2010 06:58:46 +0200, Xavier Maillard wrote: > On Mon, 12 Apr 2010 11:13:30 +0100, David Edmondson wrote: > > commit e55dc251b9e8001fe16873fadac565563e606d69 > > Author: David Edmondson > > Date: Mon Apr 12 11:12:23 2010 +0100 > > > > emacs: Add notmuch-hello.el, a friendly frontend to notmuch > > I like it ! There's an updated version in the `dme-play' branch of git://github.com/dme/notmuch.git. dme. -- David Edmondson, http://dme.org
[PATCH] emacs: Add notmuch-hello.el, a friendly frontend to notmuch
On Mon, 12 Apr 2010, David Edmondson wrote: > commit e55dc251b9e8001fe16873fadac565563e606d69 > Author: David Edmondson > Date: Mon Apr 12 11:12:23 2010 +0100 > > emacs: Add notmuch-hello.el, a friendly frontend to notmuch Hi dme, thanks for the great patch. For next time, could you plese use 'git format-patch' for generating patches for sending in email? If I pipe your message to 'git am', all the above text becomes a part of commit message. -Michal
[PATCH] emacs: Add notmuch-hello.el, a friendly frontend to notmuch
On Tue, 13 Apr 2010 12:25:43 +0200, Michal Sojka wrote: > For next time, could you plese use 'git format-patch' for generating > patches for sending in email? If I pipe your message to 'git am', all > the above text becomes a part of commit message. Will do. dme. -- David Edmondson, http://dme.org
[PATCH] Add simplistic reimplementation of strcasestr to compat library
On Tue, 13 Apr 2010 15:59:24 +1000, Anthony Towns wrote: > On Tue, Apr 13, 2010 at 14:10, Dirk Hohndel wrote: > > +/* the semantic here actually puzzles me: > > + ? how can haystack be const char * - yet the return value is char * > > + ? after all, it points to a sub-string of haystack... */ > > Dunno if this is a question from the original source, but the answer No, that was me being puzzled :-) > if anyone's interested is probably because C doesn't have templates -- > you'd ideally like to have it treated as: > > char *strcasestr(char *haystack, const char *needle); > > for when you're doing a search and replace on the needle (say), and: > > const char *strcasestr(const char *haystack, const char *needle); > > for when you're doing a search for the needle in something you can't > modify. But C isn't clever enough to let you say that with just one > function (and no fancy #defines), so you have to drop some of the > typechecking with the (char*) cast on the return value if you want to > handle both use cases, without the compiler complaining about > const->non-const conversions in otherwise correct code in one case or > the other. That makes sense. Thanks /D -- Dirk Hohndel Intel Open Source Technology Center
[PATCH] emacs: when archiving move the cursor depending on the sort order.
The current hardcoded behaviour will not take you to the next unread thread when the sort order is set to newer-first from the default of older-first. Signed-off-by: Servilio Afre Puentes --- emacs/notmuch.el |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 517c53a..728aa2b 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -572,7 +572,9 @@ thread or threads in the current region." This function advances the next thread when finished." (interactive) (notmuch-search-remove-tag-thread "inbox") - (forward-line)) + (if notmuch-search-oldest-first + (forward-line) +(previous-line))) (defun notmuch-search-process-sentinel (proc msg) "Add a message to let user know when \"notmuch search\" exits" -- 1.7.0.4
[PATCH] emacs: Extend the archive function to operate on regions too.
Signed-off-by: Servilio Afre Puentes --- emacs/notmuch.el | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 517c53a..4d4971f 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -264,7 +264,7 @@ For a mouse binding, return nil." (define-key map "f" 'notmuch-search-filter) (define-key map [mouse-1] 'notmuch-search-show-thread) (define-key map "*" 'notmuch-search-operate-all) -(define-key map "a" 'notmuch-search-archive-thread) +(define-key map "a" 'notmuch-search-archive-thread-or-region) (define-key map "-" 'notmuch-search-remove-tag) (define-key map "+" 'notmuch-search-add-tag) (define-key map (kbd "RET") 'notmuch-search-show-thread) @@ -359,7 +359,7 @@ participants in the thread, a representative subject line, and any tags). Pressing \\[notmuch-search-show-thread] on any line displays that thread. The '\\[notmuch-search-add-tag]' and '\\[notmuch-search-remove-tag]' -keys can be used to add or remove tags from a thread. The '\\[notmuch-search-archive-thread]' key +keys can be used to add or remove tags from a thread. The '\\[notmuch-search-archive-thread-or-region]' key is a convenience for archiving a thread (removing the \"inbox\" tag). The '\\[notmuch-search-operate-all]' key can be used to add or remove a tag from all threads in the current buffer. @@ -566,12 +566,12 @@ thread or threads in the current region." (notmuch-search-remove-tag-region tag beg end)) (notmuch-search-remove-tag-thread tag -(defun notmuch-search-archive-thread () - "Archive the currently selected thread (remove its \"inbox\" tag). +(defun notmuch-search-archive-thread-or-region () + "Archive the currently selected thread or region (remove its \"inbox\" tag). This function advances the next thread when finished." (interactive) - (notmuch-search-remove-tag-thread "inbox") + (notmuch-search-remove-tag "inbox") (forward-line)) (defun notmuch-search-process-sentinel (proc msg) -- 1.7.0.4
[notmuch] [PATCH] Store thread ids for messages that we haven't seen yet
On Sat, 13 Mar 2010 16:27:57 -0500, James Westby wrote: > This allows us to thread messages even when we receive them out of > order, or never receive the root. Thanks for this patch, James! It's especially nice to have the fix come in with additions to the test suite as well. I did split up the commit so the addition to the test suite happens first. That way it's easy to test the test itself, (verifying that it fails before the fix, and then passes after the fix). I also added a few documentation and other cleanups as follow-on commits. Hopefully, they don't change the logic at all, but make things easier to understand. So that's all pushed. Then, I started implementing support for retroactively storing thread_ids for non-existing messages references in already-existing messages. It took me perhaps too long that a change like that, (while useful), is too invasive for the current 0.2 release, and not essential for this particular feature. So I've postponed that part at least. I hope to make a database-schema upgrade a key part of a release in a couple of cycles, (for this feature and for "list:" and "folder:"). -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100413/4eb398fd/attachment.pgp>
[notmuch] [PATCH] json_quote_str should handle non-ASCII characters
On Thu, 04 Mar 2010 11:40:03 +0100, Gregor Hoffleit wrote: > The current code in json_quote_str() only accepts strict printable ASCII > code points (i.e. 32-127), all other code points are dropped from the > JSON output. > > This patch accepts code points 32-255. Thanks, Gregor! I've pushed this patch out now. And I noted in our TODO file that we really should add some tests to the test suite to exercise our --format=json code paths. It would be nice to ensure we don't have any regressions in this area later. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100413/9b68e96e/attachment.pgp>
[notmuch] [PATCH] Store thread ids for messages that we haven't seen yet
On Tue, 13 Apr 2010 08:20:48 -0700, Carl Worth wrote: > Thanks for this patch, James! It's especially nice to have the fix come > in with additions to the test suite as well. Thanks for including a test suite I could add to! > I did split up the commit so the addition to the test suite happens > first. That way it's easy to test the test itself, (verifying that it > fails before the fix, and then passes after the fix). Your choice. I prefer putting them in the same commit to be more self-documenting, and then using the capabilities of my VCS to verify the change if i desire. > I also added a few documentation and other cleanups as follow-on > commits. Hopefully, they don't change the logic at all, but make things > easier to understand. > > So that's all pushed. Great, thanks. > Then, I started implementing support for retroactively storing > thread_ids for non-existing messages references in already-existing > messages. It took me perhaps too long that a change like that, (while > useful), is too invasive for the current 0.2 release, and not essential > for this particular feature. This would fix up threads for all existing messages? Probably a good thing to have, but not that important to me. In my case I can always open the bug in my browser if I want to see the full conversation. > So I've postponed that part at least. I hope to make a database-schema > upgrade a key part of a release in a couple of cycles, (for this > feature and for "list:" and "folder:"). Cool, I look forward to it. Thanks, James
[notmuch] [PATCH] Add count command to manual page
On Thu, 18 Mar 2010 21:43:57 +0100, Sandra Snan wrote: > Just found out that I?ve been piping things through wc for no reason. > Heh. Here?s a quick patch, if you want to add this to the manual page. Yikes! I'm sorry that we had such a big omission in our manual page. And thanks for sending the patch. I'm sorry that I was so behind on the mailing-list backlog that I didn't notice this and apply it right away. Instead, during some recent updates to the manual page, I noticed that this was missing and already added it. But please keep suggestions for improvement coming! -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100413/bd3a780c/attachment.pgp>
[notmuch] [PATCH] Fix typo in notmuch.h documentation regarding database open modes
On Fri, 26 Mar 2010 18:39:17 +, Michael Forney wrote: > --- > lib/notmuch.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Thanks so much, Michael! I added a paragraph of "why" to the commit message and pushed this out. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100413/220107fb/attachment.pgp>
[notmuch] [PATCH] Prevent data loss caused by SIGINT during notmuch new
On Tue, 30 Mar 2010 10:23:23 +0200, Michal Sojka wrote: > When Ctrl-C is pressed in a wrong time during notmuch new, it can lead > to removal of messages from the database even if the files were not > removed. > > It happened at least once to me. > > Signed-off-by: Michal Sojka Thanks so much, Michal! This was a very bad bug that I'm sure I introduced myself when implementing rename support. Thanks to Sebastian for reminding me to pick this up for the 0.2 release. And, everyone, if I'm behind on patches, (which has always been the case so far with this project...), please feel free to make plenty of noise when there are known fixes for data-loss bugs. We really shouldn't let those sit for a couple of weeks! -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100413/665624a9/attachment.pgp>
[notmuch] [PATCH] Do not segfault on empty mime parts
On Tue, 2 Mar 2010 16:31:28 +0100, "martin f. krafft" wrote: > notmuch previously unconditionally checked mime parts for various > properties, but not for NULL, which is the case if libgmime encounters > an empty mime part. Thanks for the fix. > Upon encounter of an empty mime part, the following is printed to > stderr (the second line due to my patch): > > (process:17197): gmime-CRITICAL **: g_mime_message_get_mime_part: assertion > `GMIME_IS_MESSAGE (message)' failed > Warning: Not indexing empty mime part. That message is all quite ugly. I'm perpetually annoyed by libraries that claim to detect major problems, (even "CRITICAL" problems!), and just print messages and march along. Either there *is* a critical problem here, in which case the library should halt after printing the message, (see for example, what notmuch does with its INTERNAL_ERROR macro), or there's no problem at all and the code should operate correctly without these obnoxious messages. Anyway, I've put a note into TODO that we should do the following (in order): 1. Add a test case to trigger this message 2. File a bug against GMime to eliminate its portion of the message 3. Remove the notmuch portion of the message -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100413/5b85b352/attachment.pgp>
Plans for the 0.2 release (this week)
On Thu, 08 Apr 2010 09:47:00 +0200, "Sebastian Spaeth" wrote: > First of all, thanks for the great work Carl. I have to admit I was > getting nervous about the backlog of patches, but your recent committing > binge (you did say your work patterns are bursty :-)) made me very happy. You're quite welcome. And the big backlog was making me nervous too. I'm not sure that the backlog has gotten any smaller yet, but I'm really happy with where things are going. I seem to have created a code hydra, where every time I merge one patch, people get excited to and send me three more patches. > That having said, I am glad to meet your expectation: "I expect people > to remind me of their favorite features that haven't been merged..." > :-) Thanks for the very useful list, Sebastian. These are all merged now, (as mentioned in the replies I've made to the original messages with the patches). > > * Some library additions (move_to_first for the iterators, > +1! That one I've got noted on a separate list. > All the rest souds very good. I really do need a thread-splitting feature in order to use notmuch as my feature tracker. A list like the above of "6 trivial patches to merge" is easy to handle as a single item. I can send a message like this one saying "I'm done with this list". But several different people did reply to my original "plans for 0.2" call for features. So the single thread I have for this in my "notmuch merge window" search is not doing the trick. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100413/0d0eaebc/attachment-0001.pgp>
Plans for the 0.2 release (this week)
On Thu, 08 Apr 2010 09:52:21 -0400, Jameson Rollins wrote: > I would really like to see the patch in spaetz/issue15-handle-fcc-bcc > applied soon. This is the lingering issue of bcc'ing the primary email > address in notmuch replies, which I think really needs to be removed. > > Let me know if there are any issues. I'm pretty sure this will apply > cleanly against the head without a rebase. I'm happy to remove the Bcc thing, but only *after* we have an Fcc approach integrated into the emacs client by default, (without users having to configure it, download python scripts, etc.). And yes, I know the current Bcc approach is still quite useless, because it only triggers on replies, (and not when composing a new message from the emacs client). I'm looking forward to seeing this all fixed, but I haven't yet seen a "packaged" solution. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100413/35f72108/attachment.pgp>
[notmuch] [PATCH] notmuch.el: quote args in notmuch-show to facilitate remote use
On Sun, 24 Jan 2010 15:22:33 -0500, Jesse Rosenthal wrote: > Put single-quotes around the argument of the `show --entire-thread' command > in notmuch-show. Thanks for this, Jesse! I've merged this change now, and (as documented) I don't notice any change. I am quite interested in playing with the "use notmuch over ssh" stuff you've been doing, (and that you described in the original follow-up to this patch). Perhaps you (or someone else) would like to maintain a wiki page showing how that can be used until we get remote support more properly integrated into notmuch itself. Thanks again, -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100413/60901edb/attachment.pgp>
[PATCH] First tests for JSON output and UTF-8 in mail body and subject
The test suite doesn't yet cover --format=json output nor UTF-8 in subject or body. This patch starts with test cases for 'search --format=json' and 'show --format=json'. Furthermore, it has test cases for a search for a UTF-8 string in a mail body for a UTF-8 string in a mail subject. Finally, it has a test case for --format=json with UTF-8 messages, demonstrating the fix in 1267697893-sup-4538 at sam.mediasupervision.de. --- test/notmuch-test | 38 ++ 1 files changed, 38 insertions(+), 0 deletions(-) diff --git a/test/notmuch-test b/test/notmuch-test index 1c5191b..b2a0756 100755 --- a/test/notmuch-test +++ b/test/notmuch-test @@ -146,7 +146,7 @@ add_message () } NOTMUCH_IGNORED_OUTPUT_REGEXP='^Processed [0-9]*( total)? file|Found [0-9]* total file' -NOTMUCH_THREAD_ID_SQUELCH='s/thread:/thread:XXX/' +NOTMUCH_THREAD_ID_SQUELCH='s/thread:/thread:XXX/;s/"thread": "",/"thread": "XXX",/' execute_expecting () { args=$1 @@ -348,6 +348,42 @@ add_message '[subject]="body search (phrase)"' '[date]="Sat, 01 Jan 2000 12:00:0 add_message '[subject]="negative result"' '[date]="Sat, 01 Jan 2000 12:00:00 -"' '[body]="This phrase should not match the body search"' execute_expecting "search '\"body search (phrase)\"'" "thread:XXX 2000-01-01 [1/1] Notmuch Test Suite; body search (phrase) (inbox unread)" +printf " Show message: json...\t\t" +add_message '[subject]="json-show-subject"' '[date]="Sat, 01 Jan 2000 12:00:00 -"' '[body]="json-show-message"' +execute_expecting "show --format=json 'json-show-message'" '[[[{"id": "'${gen_msg_id}'", "match": true, "filename": "'${gen_msg_filename}'", "date_unix": 946728000, "date_relative": "2000-01-01", "tags": ["inbox","unread"], "headers": {"Subject": "json-show-subject", "From": "Notmuch Test Suite ", "To": "Notmuch Test Suite ", "Cc": "", "Bcc": "", "Date": "Sat, 01 Jan 2000 12:00:00 -"}, "body": [{"id": 1, "content-type": "text/plain", "content": "json-show-message\n"}]}, [' + +printf " Search message: json...\t" +add_message '[subject]="json-search-subject"' '[date]="Sat, 01 Jan 2000 12:00:00 -"' '[body]="json-search-message"' +execute_expecting "search --format=json 'json-search-message'" '[{"thread": "XXX", +"timestamp": 946724400, +"matched": 1, +"total": 1, +"authors": "Notmuch Test Suite", +"subject": "json-search-subject", +"tags": ["inbox", "unread"]}]' + +printf " Search by subject (utf-8):...\t" +add_message [subject]=utf8-s?bj?ct '[date]="Sat, 01 Jan 2000 12:00:00 -"' +execute_expecting "search subject:utf8-s?bj?ct" "thread:XXX 2000-01-01 [1/1] Notmuch Test Suite; utf8-s?bj?ct (inbox unread)" + +printf " Search body (utf-8):...\t" +add_message '[subject]="utf8-message-body-subject"' '[date]="Sat, 01 Jan 2000 12:00:00 -"' '[body]="message body utf8: b?d?"' +execute_expecting "search 'b?d?'" "thread:XXX 2000-01-01 [1/1] Notmuch Test Suite; utf8-message-body-subject (inbox unread)" + +printf " Show message: json, utf-8...\t" +add_message '[subject]="json-show-utf8-body-s?bj?ct"' '[date]="Sat, 01 Jan 2000 12:00:00 -"' '[body]="js?n-show-m?ssage"' +execute_expecting "show --format=json 'js?n-show-m?ssage'" '[[[{"id": "'${gen_msg_id}'", "match": true, "filename": "'${gen_msg_filename}'", "date_unix": 946728000, "date_relative": "2000-01-01", "tags": ["inbox","unread"], "headers": {"Subject": "json-show-utf8-body-s?bj?ct", "From": "Notmuch Test Suite ", "To": "Notmuch Test Suite ", "Cc": "", "Bcc": "", "Date": "Sat, 01 Jan 2000 12:00:00 -"}, "body": [{"id": 1, "content-type": "text/plain", "content": "js?n-show-m?ssage\n"}]}, [' + +printf " Search message: json, utf-8...\t" +add_message '[subject]="json-search-utf8-body-s?bj?ct"' '[date]="Sat, 01 Jan 2000 12:00:00 -"' '[body]="js?n-search-m?ssage"' +execute_expecting "search --format=json 'js?n-search-m?ssage'" '[{"thread": "XXX", +"timestamp": 946724400, +"matched": 1, +"total": 1, +"authors": "Notmuch Test Suite", +"subject": "json-search-utf8-body-s?bj?ct", +"tags": ["inbox", "unread"]}]' + printf " Search by from: (address)...\t" add_message '[subject]="search by from (address)"' '[date]="Sat, 01 Jan 2000 12:00:00 -"' [from]=searchbyfrom at example.com execute_expecting "search from:searchbyfrom at example.com" "thread:XXX 2000-01-01 [1/1] searchbyfrom at example.com; search by from (address) (inbox unread)"
[notmuch] [PATCH] Decode headers in reply
On Wed, 3 Mar 2010 08:50:56 +0100, Michal Sojka wrote: > When headers contain non-ASCII characters, they are encoded according > to rfc2047. Nomtuch reply command emits the headers in the encoded > form, which makes them hard to read by humans who compose the reply. This feature is obviously extremely handy. So thank you, Michal! I've now pushed this out. I think the implementation is over-complicated, but that's almost entirely the fault of GMime and GObject, not yours. We are creating a GMime object to represent the message and then asking GMime to print it. GMime then does what it should (assuming the message is going to be sent over SMTP) and encodes the headers. We don't happen to want this encoding, since the client wants to allow the user to edit the message and only encode the final result. There is a single function that GMime provides for the decoding (g_mime_utils_header_decode_text) but arranging for GMime to call this function on each header requires over 200 lines of code with the hideous GObject boilerplate and a bunch of replicated parsing code. Meanwhile, what's GMime actually doing for us here? We have the original decoded strings in the first place. And we know how to print "Subject:", "To:", and "From:". So what do we need GMime for the headers? The only thing I can think of is that GMime is also inserting RFC-compliant wrapping of long lines. But since we want to let the user edit the subject, etc. anyway, don't we have to rely on the client to do that *anyway*? Incidentally, it looks like message-mode does have support to do RCF-compliant line wrapping if I hit M-q (`fill-paragraph') on a long Subject: line but it doesn't appear to do that automatically. Instead, it will just send a non-RFC-compliant message if I just type a long Subject line. That looks like yet another reason to have a notmuch-message-mode that extends message-mode and fixes several issues we've been identifying. Back to the patch though, I have pushed this out, but I've also added a TODO item for simplifying this stuff. I think a handful of calls to printf would be much better than this big pile of GObject boilerplate and ad-hoc parsing. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100413/cc04e323/attachment.pgp>
Plans for the 0.2 release (this week)
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: > > * Any further changes from the Sebastian's repository. Sebastian, I > worked through one list I saw recently. Do you have another list to > propose yet? Sebastian sent a list of these, and they are merged now. > * The big batch of emacs-client improvements from David E.'s > repository. David, do you have particular things to recommend > here? David has no followed up with a rebase of his entire branch. It looks *very* nice still but won't be in 0.2. I plan to land this early and make it the focus of the 0.3 release. > * Changes to indexing, (addition of body:, folder:, list:, etc.). This > is stuff that I'll work on. I haven't gotten to this yet. It's a big change, (in that it requires everyone to rebuild their database). So this will need some careful testing. And I'd like to get as many changes in at once so we won't all have to rebuild are databases in the following release. This stuff will be the focus of the 0.4 release. > * Some library additions (move_to_first for the iterators, and perhaps > a notmuch_database_add_message_with_data which Srinivasa requested > to support integration of notmuch into evolution). I'll work on > these as well, (I know that there are patches for some of these on > the list already). I'll take a look at the existing patches for the iterators. That's still 0.2 material. The add_message_with_data feature will come later. > * Anything else that people want, (especially things that already > exist and that you're already using). Thanks for several suggestions in reply to this message. I think they are all merged now. Let me know if I missed anything. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100413/943c9a0a/attachment.pgp>
[PATCH] Fix code extracting the MTA from Received: headers
On Thu, 08 Apr 2010 08:07:48 -0700, Dirk Hohndel wrote: > Right now my plan is to do something like this: > > 1) look for my email address in To/Cc > 2) look for my email in "for " in Received headers > 3) look for my email in X-Original-To > 4) look for the domain of my email in Received headers (not just 1st) > 5) punt and use default email address > > Does that sound sane? It sounds sane. > (and thanks for sending the headers - this really helps... can others > for whom the current code or the logic mentioned above wouldn't work > send their headers, too, please?) I started using fetchmail many years ago and have never really needed to switch. So I'm still using that, (but don't necessarily recommend it to anyone. It seems to break the above since it delivers mail locally, so the first headers I get are: X-Original-To: cworth at localhost Delivered-To: cworth at localhost Received: from yoom.home.cworth.org (yoom.home.cworth.org [127.0.0.1]) by yoom.home.cworth.org (Postfix) with ESMTP id D391B5883A6 for ; Mon, 12 Apr 2010 09:11:18 -0700 (PDT) MIME-Version: 1.0 Received: from 10.22.226.213 [10.22.226.213] by yoom.home.cworth.org with IMAP (fetchmail-6.3.16) for (single-drop); Mon, 12 Apr 2010 09:11:18 -0700 (PDT) And none of these are useful for your detection. Worse, the presence of "cworth.org" in the above might throw your detection off before it could find something useful like "intel.com" in a later Received header. I'll send a complete message with full headers to you separately. Perhaps I can just switch programs to transfer email and avoid this problem. Anyone have a recommendation for something to transfer mail
[PATCH] RFC: User-Agent header
On Mon, 12 Apr 2010 10:30:54 +0200, "Sebastian Spaeth" wrote: > > OK, final post from me on this issue. No, wait! I want more from you. :-) Would you care to put together a solution that does this from within notmuch*.el ? I really want things usable by default without people having to hack up their .emacs files. Of course, we could also easily add a variable to make this not happen, (but that can be added in a follow-on patch by anyone). Thanks, -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100413/192eeefc/attachment.pgp>
[PATCH 1/4] Mailstore abstraction interface
On Thu, 8 Apr 2010 16:42:43 +0200, Michal Sojka wrote: > The goal of mailstore abstraction is to allow notmuch to store tags > together with email messages. The abstract interface is needed because > people want to use different ways of storing their emails. Currently, > there exists implementation for two types of mailstore - plain files > and maildir. It is expected that additional git-based mailstore will > be developed later. I don't agree with the approach being taken here. I don't think that the expectation of future need is a good basis for adding a level of abstraction now. This gives us current costs without benefit. Meanwhile, the two different mail stores that you are currently support ("plain" and "maildir") aren't really different types. We do already have code within notmuch to detect whether any particular directory is a maildir, (with the heuristic of looking for child directories named "cur", "new", and "tmp"). So I think we can and should support both maildir and non-maildir mail storage just fine. The question of "once you have maildir storage, should you synchronize that tags" is quite separate. The answer there might be "yes", "no", or "let the user decide". But if it is configurable, then the configuration should be something like [maildir] synchronize_flags=yes rather than [mailstore] type=maildir This series is looking like one of the most complete approaches to maildir-flag synchronization, (and I like some of the motivation that leads to "notmuch cat"). But I think the mailstore abstraction is largely a distraction from the real features here. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100413/415e8dc2/attachment-0001.pgp>
[notmuch] [PATCH v2] notmuch.el: add functionality in notmuch search mode to add or remove tags by region
On Fri, 09 Apr 2010 10:11:00 -0400, Jesse Rosenthal wrote: > I'll play with both and see which is clearer. Any progress here, Jesse? I'd like to release notmuch 0.2 soon and would prefer not to revert this feature, (but I also don't really want to ship it with this known bug). -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100413/160ebce6/attachment.pgp>
[notmuch] [PATCH v2] notmuch.el: add functionality in notmuch search mode to add or remove tags by region
Sorry -- just got back into town from some business travel. I'll be working on it this afternoon, and will let you know by this evening where I get with it. Best, Jesse On Tue, 13 Apr 2010 10:55:55 -0700, Carl Worth wrote: > On Fri, 09 Apr 2010 10:11:00 -0400, Jesse Rosenthal > wrote: > > I'll play with both and see which is clearer. > > Any progress here, Jesse? > > I'd like to release notmuch 0.2 soon and would prefer not to revert this > feature, (but I also don't really want to ship it with this known bug). > > -Carl Non-text part: application/pgp-signature
An update on 0.2 progress
I just wanted to let everyone know that I think the code for the 0.2 release of notmuch is pretty much in place now. I've either merged or decided to postpone most all of the proposed features. I'll follow-up with another mail giving the detailed list of features that have been merged or postponed, and I'd like to release 0.2 by the end of the day today. In the meantime, here are 3 small things still left: * Investigate patches to add the move_to_first iterator improvements * Revert support for "*" as a search term. I threw this in while merging the support for "notmuch count" with no arguments, but it's quite broken currently, (scrambled dates in output of "notmuch search *" output, broken support for filtering a "*" search in the emacs code). * Perhaps revert the region-based tag feature in the notmuch interface. This has a bug leading to a very confusing failure mode when the region includes the last line of the buffer. I'd prefer to see a fix before 0.2, but I could revert this feature instead. Thanks for all the work going in already. There's a bunch of good stuff here, (and some stuff I was sad to see not make the cut---but that gives us something to look forward to next week!). -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100413/fb117691/attachment.pgp>
[PATCH] Fix code extracting the MTA from Received: headers
On Tue, 13 Apr 2010 10:37:49 -0700, Carl Worth wrote: > On Thu, 08 Apr 2010 08:07:48 -0700, Dirk Hohndel > wrote: > > Right now my plan is to do something like this: > > > > 1) look for my email address in To/Cc > > 2) look for my email in "for " in Received headers > > 3) look for my email in X-Original-To > > 4) look for the domain of my email in Received headers (not just 1st) > > 5) punt and use default email address > > > > Does that sound sane? > > It sounds sane. Good. > > (and thanks for sending the headers - this really helps... can others > > for whom the current code or the logic mentioned above wouldn't work > > send their headers, too, please?) > > I started using fetchmail many years ago and have never really needed to > switch. So I'm still using that, (but don't necessarily recommend it to > anyone. > > It seems to break the above since it delivers mail locally, so the first > headers I get are: > > X-Original-To: cworth at localhost Easy to detect. I'll add that as an exclusion > Delivered-To: cworth at localhost > Received: from yoom.home.cworth.org (yoom.home.cworth.org [127.0.0.1]) > by yoom.home.cworth.org (Postfix) with ESMTP id D391B5883A6 > for ; Mon, 12 Apr 2010 09:11:18 -0700 (PDT) > MIME-Version: 1.0 > Received: from 10.22.226.213 [10.22.226.213] > by yoom.home.cworth.org with IMAP (fetchmail-6.3.16) > for (single-drop); Mon, 12 Apr 2010 > 09:11:18 -0700 (PDT) A (he runs screaming out of the room) > And none of these are useful for your detection. Worse, the presence of > "cworth.org" in the above might throw your detection off before it could > find something useful like "intel.com" in a later Received header. I have some choice words for these headers... And an idea how to exclude these false positives as well... It's kind of a hack, but I'm thinking that in order for the "Received: ... by ..." part to be truly relevant to us, the from host should have a non-private IP address. Yes, I can envision within-your-own-network cases where none of the systems have a non-private email address... but then hopefully your last hop is correct... if not - your setup is even more screwed up than Carl's. > I'll send a complete message with full headers to you separately. Thanks > Perhaps I can just switch programs to transfer email and avoid this > problem. Anyone have a recommendation for something to transfer mail > From an imap server to the local matchine, (but *not* leaving it stored > on the imap server)[*]. I don't think offlineimap supports this mode > does it? Don't think so. I'm not going to comment on the usefulness of this mode in public :-) /D -- Dirk Hohndel Intel Open Source Technology Center
[PATCH] Add strcasestr v.3 - add compat implementation of strcasestr
v.3 of this patch, now with the changes to makefiles, configure script compat.h and all new files that I need Please test on platforms lacking strcasestr Signed-off-by: Dirk Hohndel --- compat/Makefile.local|4 compat/compat.h |4 compat/have_strcasestr.c | 10 ++ compat/strcasestr.c | 41 + configure| 20 ++-- 5 files changed, 77 insertions(+), 2 deletions(-) create mode 100644 compat/have_strcasestr.c create mode 100644 compat/strcasestr.c diff --git a/compat/Makefile.local b/compat/Makefile.local index 81e6c70..2a17309 100644 --- a/compat/Makefile.local +++ b/compat/Makefile.local @@ -8,3 +8,7 @@ notmuch_compat_srcs = ifneq ($(HAVE_GETLINE),1) notmuch_compat_srcs += $(dir)/getline.c $(dir)/getdelim.c endif + +ifneq ($(HAVE_STRCASESTR),1) +notmuch_compat_srcs += $(dir)/strcasestr.c +endif diff --git a/compat/compat.h b/compat/compat.h index d639e0f..173ef68 100644 --- a/compat/compat.h +++ b/compat/compat.h @@ -38,4 +38,8 @@ getdelim (char **lineptr, size_t *n, int delimiter, FILE *fp); #endif /* !HAVE_GETLINE */ +#if !HAVE_STRCASESTR +char* strcasestr(const char *haystack, const char *needle); +#endif /* !HAVE_STRCASESTR */ + #endif /* NOTMUCH_COMPAT_H */ diff --git a/compat/have_strcasestr.c b/compat/have_strcasestr.c new file mode 100644 index 000..c0fb762 --- /dev/null +++ b/compat/have_strcasestr.c @@ -0,0 +1,10 @@ +#define _GNU_SOURCE +#include + +int main() +{ +char *found; +const char *haystack, *needle; + +found = strcasestr(haystack, needle); +} diff --git a/compat/strcasestr.c b/compat/strcasestr.c new file mode 100644 index 000..50bc89d --- /dev/null +++ b/compat/strcasestr.c @@ -0,0 +1,41 @@ +/* + * slow simplistic reimplementation of strcasestr for systems that + * don't include it in their library + * + * based on a GPL implementation in OpenTTD found under GPL v2 + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation, version 2. + + This program is distributed in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA + 02110-1301, USA. */ + +/* Imported into notmuch by Dirk Hohndel - original author unknown. */ +/* the semantic here actually puzzles me: + how can haystack be const char * - yet the return value is char * + after all, it points to a sub-string of haystack... */ + +#include + +char *strcasestr(const char *haystack, const char *needle) +{ + size_t hay_len = strlen(haystack); + size_t needle_len = strlen(needle); + while (hay_len >= needle_len) { + if (strncasecmp(haystack, needle, needle_len) == 0) + return (char *) haystack; + + haystack++; + hay_len--; + } + + return NULL; +} diff --git a/configure b/configure index 5af7852..90a399c 100755 --- a/configure +++ b/configure @@ -310,6 +310,17 @@ else fi rm -f compat/have_getline +printf "Checking for strcasestr... " +if ${CC} -o compat/have_strcasestr compat/have_strcasestr.c > /dev/null 2>&1 +then +printf "Yes.\n" +have_strcasestr=1 +else +printf "No (will use our own instead).\n" +have_strcasestr=0 +fi +rm -f compat/have_strcasestr + cat <
[PATCH] Add simplistic compat implementation for strcasestr
v.2 of the patch, this time including the Makefile logic. All platforms I have access to support strcasestr - so please test that the implementation / integration works correctly on those plattforms. Signed-off-by: Dirk Hohndel --- compat/have_strcasestr.c | 10 ++ compat/strcasestr.c | 41 + 2 files changed, 51 insertions(+), 0 deletions(-) create mode 100644 compat/have_strcasestr.c create mode 100644 compat/strcasestr.c diff --git a/compat/have_strcasestr.c b/compat/have_strcasestr.c new file mode 100644 index 000..c0fb762 --- /dev/null +++ b/compat/have_strcasestr.c @@ -0,0 +1,10 @@ +#define _GNU_SOURCE +#include + +int main() +{ +char *found; +const char *haystack, *needle; + +found = strcasestr(haystack, needle); +} diff --git a/compat/strcasestr.c b/compat/strcasestr.c new file mode 100644 index 000..50bc89d --- /dev/null +++ b/compat/strcasestr.c @@ -0,0 +1,41 @@ +/* + * slow simplistic reimplementation of strcasestr for systems that + * don't include it in their library + * + * based on a GPL implementation in OpenTTD found under GPL v2 + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License as + published by the Free Software Foundation, version 2. + + This program is distributed in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA + 02110-1301, USA. */ + +/* Imported into notmuch by Dirk Hohndel - original author unknown. */ +/* the semantic here actually puzzles me: + how can haystack be const char * - yet the return value is char * + after all, it points to a sub-string of haystack... */ + +#include + +char *strcasestr(const char *haystack, const char *needle) +{ + size_t hay_len = strlen(haystack); + size_t needle_len = strlen(needle); + while (hay_len >= needle_len) { + if (strncasecmp(haystack, needle, needle_len) == 0) + return (char *) haystack; + + haystack++; + hay_len--; + } + + return NULL; +} -- 1.6.6.1 -- Dirk Hohndel Intel Open Source Technology Center
[PATCH] Add strcasestr v.3 - add compat implementation of strcasestr
On 4/13/10 6:47 PM, Dirk Hohndel wrote: > > v.3 of this patch, now with the changes to makefiles, configure script > compat.h and all new files that I need > Please test on platforms lacking strcasestr > > Signed-off-by: Dirk Hohndel Tested-by: Tomas Carnecky (on OpenSolaris snv_134) tom
[PATCH] Fix bug, and clean up code duplication, in adding or removing tag by region.
There was a bug in notmuch-search-{add,remove}-tag-region, which would not behave correctly if the region went beyond the last message. Now, instead of simply iterating to the last line of the region, these functions will iterate to the minimum of the last line of the region and the last possible line, i.e. (- (line-number-at-pos (point-max)) 2) Also clean up code duplication, as per Carl's suggestion, by making notmuch-search-{add/remove}-tag-thread a special case of the -region commands, where the region in question is between (point) and (point). --- emacs/notmuch.el | 26 ++ 1 files changed, 14 insertions(+), 12 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 517c53a..be09f42 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -399,10 +399,11 @@ Complete list of currently available key bindings: (defun notmuch-search-properties-in-region (property beg end) (save-excursion (let ((output nil) - (last-line (line-number-at-pos end))) + (last-line (line-number-at-pos end)) + (max-line (- (line-number-at-pos (point-max)) 2))) (goto-char beg) (beginning-of-line) - (while (<= (line-number-at-pos) last-line) + (while (<= (line-number-at-pos) (min last-line max-line)) (setq output (cons (get-text-property (point) property) output)) (forward-line 1)) output))) @@ -497,38 +498,39 @@ and will also appear in a buffer named \"*Notmuch errors*\"." (defun notmuch-search-get-tags-region (beg end) (save-excursion (let ((output nil) - (last-line (line-number-at-pos end))) + (last-line (line-number-at-pos end)) + (max-line (- (line-number-at-pos (point-max)) 2))) (goto-char beg) - (while (<= (line-number-at-pos) last-line) + (while (<= (line-number-at-pos) (min last-line max-line)) (setq output (append output (notmuch-search-get-tags))) (forward-line 1)) output))) (defun notmuch-search-add-tag-thread (tag) - (notmuch-call-notmuch-process "tag" (concat "+" tag) (notmuch-search-find-thread-id)) - (notmuch-search-set-tags (delete-dups (sort (cons tag (notmuch-search-get-tags)) 'string< + (notmuch-search-add-tag-region tag (point) (point))) (defun notmuch-search-add-tag-region (tag beg end) (let ((search-id-string (mapconcat 'identity (notmuch-search-find-thread-id-region beg end) " or "))) (notmuch-call-notmuch-process "tag" (concat "+" tag) search-id-string) (save-excursion - (let ((last-line (line-number-at-pos end))) + (let ((last-line (line-number-at-pos end)) + (max-line (- (line-number-at-pos (point-max)) 2))) (goto-char beg) - (while (<= (line-number-at-pos) last-line) + (while (<= (line-number-at-pos) (min last-line max-line)) (notmuch-search-set-tags (delete-dups (sort (cons tag (notmuch-search-get-tags)) 'string<))) (forward-line)) (defun notmuch-search-remove-tag-thread (tag) - (notmuch-call-notmuch-process "tag" (concat "-" tag) (notmuch-search-find-thread-id)) - (notmuch-search-set-tags (delete tag (notmuch-search-get-tags + (notmuch-search-remove-tag-region tag (point) (point))) (defun notmuch-search-remove-tag-region (tag beg end) (let ((search-id-string (mapconcat 'identity (notmuch-search-find-thread-id-region beg end) " or "))) (notmuch-call-notmuch-process "tag" (concat "-" tag) search-id-string) (save-excursion - (let ((last-line (line-number-at-pos end))) + (let ((last-line (line-number-at-pos end)) + (max-line (- (line-number-at-pos (point-max)) 2))) (goto-char beg) - (while (<= (line-number-at-pos) last-line) + (while (<= (line-number-at-pos) (min last-line max-line)) (notmuch-search-set-tags (delete tag (notmuch-search-get-tags))) (forward-line)) -- 1.6.5.3
[PATCH] Use wrapper functions to find the type of struct dirent
Some platforms don't provide DT_REG/DT_LNK/DT_DIR. Create wrapper functions which test the presence of those symbols and fall back to stat(2). --- Not sure if I got the handling of DT_UNKNOWN correct in all cases. Someone please double-check that. notmuch-new.c | 70 ++-- 1 files changed, 62 insertions(+), 8 deletions(-) diff --git a/notmuch-new.c b/notmuch-new.c index 44b50aa..95b 100644 --- a/notmuch-new.c +++ b/notmuch-new.c @@ -140,6 +140,62 @@ dirent_sort_strcmp_name (const struct dirent **a, const struct dirent **b) return strcmp ((*a)->d_name, (*b)->d_name); } +/* Helper functions to test if a given dirent is of a certain type + */ +static int +_is_reg(const char *path, struct dirent *entry) +{ +#ifdef DT_REG +if (entry->d_type == DT_REG) +return 1; +#endif + +char buffer[PATH_MAX]; +snprintf(buffer, PATH_MAX, "%s/%s", path, entry->d_name); + +struct stat sbuf; +if (!stat(buffer, &sbuf)) +return S_ISREG(sbuf.st_mode); + +return 0; +} + +static int +_is_dir(const char *path, struct dirent *entry) +{ +#ifdef DT_DIR +if (entry->d_type == DT_DIR) +return 1; +#endif + +char buffer[PATH_MAX]; +snprintf(buffer, PATH_MAX, "%s/%s", path, entry->d_name); + +struct stat sbuf; +if (!stat(buffer, &sbuf)) +return S_ISDIR(sbuf.st_mode); + +return 0; +} + +static int +_is_lnk(const char *path, struct dirent *entry) +{ +#ifdef DT_LNK +if (entry->d_type == DT_LNK) +return 1; +#endif + +char buffer[PATH_MAX]; +snprintf(buffer, PATH_MAX, "%s/%s", path, entry->d_name); + +struct stat sbuf; +if (!stat(buffer, &sbuf)) +return S_ISLNK(sbuf.st_mode); + +return 0; +} + /* Test if the directory looks like a Maildir directory. * * Search through the array of directory entries to see if we can find all @@ -148,12 +204,12 @@ dirent_sort_strcmp_name (const struct dirent **a, const struct dirent **b) * Return 1 if the directory looks like a Maildir and 0 otherwise. */ static int -_entries_resemble_maildir (struct dirent **entries, int count) +_entries_resemble_maildir (const char *path, struct dirent **entries, int count) { int i, found = 0; for (i = 0; i < count; i++) { - if (entries[i]->d_type != DT_DIR && entries[i]->d_type != DT_UNKNOWN) + if (!_is_dir(path, entries[i])) continue; if (strcmp(entries[i]->d_name, "new") == 0 || @@ -265,7 +321,7 @@ add_files_recursive (notmuch_database_t *notmuch, } /* Pass 1: Recurse into all sub-directories. */ -is_maildir = _entries_resemble_maildir (fs_entries, num_fs_entries); +is_maildir = _entries_resemble_maildir (path, fs_entries, num_fs_entries); for (i = 0; i < num_fs_entries; i++) { if (interrupted) @@ -280,9 +336,7 @@ add_files_recursive (notmuch_database_t *notmuch, * scandir results, then it might be a directory (and if not, * then we'll stat and return immediately in the next level of * recursion). */ - if (entry->d_type != DT_DIR && - entry->d_type != DT_LNK && - entry->d_type != DT_UNKNOWN) + if (!_is_dir(path, entry) && !_is_lnk(path, entry)) { continue; } @@ -360,7 +414,7 @@ add_files_recursive (notmuch_database_t *notmuch, * * In either case, a stat does the trick. */ - if (entry->d_type == DT_LNK || entry->d_type == DT_UNKNOWN) { + if (_is_lnk(path, entry)) { int err; next = talloc_asprintf (notmuch, "%s/%s", path, entry->d_name); @@ -376,7 +430,7 @@ add_files_recursive (notmuch_database_t *notmuch, if (! S_ISREG (st.st_mode)) continue; - } else if (entry->d_type != DT_REG) { + } else if (!_is_reg(path, entry)) { continue; } -- 1.7.0.5
[PATCH] Add strcasestr v.3 - add compat implementation of strcasestr
On Tue, 13 Apr 2010 20:47:02 +0200, Tomas Carnecky wrote: > On 4/13/10 6:47 PM, Dirk Hohndel wrote: > > > > v.3 of this patch, now with the changes to makefiles, configure script > > compat.h and all new files that I need > > Please test on platforms lacking strcasestr > > > > Signed-off-by: Dirk Hohndel > > Tested-by: Tomas Carnecky > > (on OpenSolaris snv_134) Thanks Tomas, I really appreciate it. /D -- Dirk Hohndel Intel Open Source Technology Center
[PATCH 1/4] Mailstore abstraction interface
On Tue, 13 Apr 2010 10:53:12 -0700, Carl Worth wrote: > This series is looking like one of the most complete approaches to > maildir-flag synchronization, (and I like some of the motivation that > leads to "notmuch cat"). But I think the mailstore abstraction is > largely a distraction from the real features here. For my case (of wanting to have backup of my mailstore complete in reasonable time, preferably using less disk space) of wanting mail in git packs, 'notmuch cat' being used everywhere removes a lot of the issues of doing this. (pluggin in an alternative to readdir is fairly simple... but the emacs UI needs to read from it too :) -- Stewart Smith
See only unread message in a thread ?
On Wed, 14 Apr 2010 00:11:50 +0200, Xavier Maillard wrote: > Hi, > > maybe I missread the "manual" but I can't find an easy way to do > something simple in notmuch.el. > > Say I have a thread with A-B-C. I visit the thread and read the > whole thread. Let's say after 'notmuch new' a post has entered > the thread: A-B-C-D. Is there an easy way to just have one of > these behaviour: > > - only show the new message (with an option to toggle display of > the old messages) > - display the whole thread with the 3 read messages 'collapsed' > and only the unread message 'expanded' This is the default behaviour in my experience. Reading a message unsets the 'unread' tag. The default search if for 'inbox' + 'unread'. This lists the threads where any message within matches that criterion. When viewing a thread from there the messages that don't match are collapsed. Therefore if you are remove the 'unread' tag when reading mail you will only read the newest messages when 'notmuch new' adds a new message to the thread if the search that took you there included the 'unread' tag. Thanks, James
See only unread message in a thread ?
On Tue, 13 Apr 2010 23:19:37 +0100, James Westby wrote: > On Wed, 14 Apr 2010 00:11:50 +0200, Xavier Maillard wrote: > > Say I have a thread with A-B-C. I visit the thread and read the > > whole thread. Let's say after 'notmuch new' a post has entered > > the thread: A-B-C-D. Is there an easy way to just have one of > > these behaviour: > > > > - only show the new message (with an option to toggle display of > > the old messages) > > - display the whole thread with the 3 read messages 'collapsed' > > and only the unread message 'expanded' > > This is the default behaviour in my experience. I agree this is the behavior I see, but there is a caveat that may be the cause of confusion: > Reading a message unsets the 'unread' tag. > > The default search if for 'inbox' + 'unread'. Actually, the default search is for just "tag:inbox", which will also display any messages in the inbox that have "tag:unread" as well. But remember that if you are coming from a search for "tag:inbox", when you view a thread all the message with "tag:inbox" will be visible (uncollapsed), whether or not they have "tag:unread" not. Just reading a message will not cause it to collapse when coming from a "tag:inbox" search. I think this might be where the confusion is coming from. If you want to view just the messages in your inbox that are unread, then you need to search for "tag:inbox and tag:unread", or type 'f' in notmuch mode to filter your inbox search with the "tag:unread" search. Make sense? 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/20100413/b0d41cc4/attachment.pgp>
[PATCH 0/4] Mailstore abstraction v4
On Thu, 8 Apr 2010 16:42:42 +0200, Michal Sojka wrote: > My biggest question relates to the first patch, which does an > incompatible change to libnotmuch API. After reading RELEASING file, I > found that this change is probably not what Carl wants to merge (and I > understand that) so I'd like to get some feedback on my suggestion in > that patch. [I composed this message a while ago, but failed to get it through the mailing-list moderation until now. It may be largely irrelevant in light of my more recent review of the mailstore abstraction, but here it is.] I haven't looked closely at the implementation here, but a quick glance at the API/ABI change suggests an easy answer: Why not just add a new function that accepts the mailstore type, and preserve the original function, (which would then simply call the new function with an argument of "files" for the mailstore type). -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100413/fa35bb5e/attachment.pgp>