[PATCH] Use wrapper functions to find the type of struct dirent

[Tomas Carnecky]

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, ))
+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, ))
+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, ))
+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

[Tomas Carnecky]

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

See only unread message in a thread ?

[Jameson Rollins]

On Tue, 13 Apr 2010 23:19:37 +0100, James Westby <jw+debian at jameswestby.net> 
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] First tests for JSON output and UTF-8 in mail body and subject

[Gregor Hoffleit]

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] Store thread ids for messages that we haven't seen yet

[James Westby]

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

[PATCH] Add simplistic reimplementation of strcasestr to compat library

[Anthony Towns]

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 1/4] Mailstore abstraction interface

[Stewart Smith]

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

[PATCH] Fix bug, and clean up code duplication, in adding or removing tag by region.

[Jesse Rosenthal]

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] [PATCH v2] notmuch.el: add functionality in notmuch search mode to add or remove tags by region

[Jesse Rosenthal]

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

[PATCH] Add strcasestr v.3 - add compat implementation of strcasestr

[Dirk Hohndel]

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] emacs: Add notmuch-hello.el, a friendly frontend to notmuch

[Michal Sojka]

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 0/4] Mailstore abstraction v4

[Carl Worth]

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>

[PATCH] emacs: Add notmuch-hello.el, a friendly frontend to notmuch

[David Edmondson]

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] Fix code extracting the MTA from Received: headers

[Dirk Hohndel]

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

An update on 0.2 progress

[Carl Worth]

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>

[notmuch] [PATCH v2] notmuch.el: add functionality in notmuch search mode to add or remove tags by region

[Carl Worth]

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>

[PATCH 1/4] Mailstore abstraction interface

[Carl Worth]

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>

[PATCH] RFC: User-Agent header

[Carl Worth]

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] Fix code extracting the MTA from Received: headers

[Carl Worth]

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

Plans for the 0.2 release (this week)

[Carl Worth]

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>

[notmuch] [PATCH] Decode headers in reply

[Carl Worth]

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>

[PATCH] Add strcasestr v.3 - add compat implementation of strcasestr

[Dirk Hohndel]

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 <

[notmuch] [PATCH] notmuch.el: quote args in notmuch-show to facilitate remote use

[Carl Worth]

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] Add simplistic compat implementation for strcasestr

[Dirk Hohndel]

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

Plans for the 0.2 release (this week)

[Carl Worth]

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>

[PATCH] emacs: Extend the archive function to operate on regions too.

[Servilio Afre Puentes]

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

[PATCH] emacs: when archiving move the cursor depending on the sort order.

[Servilio Afre Puentes]

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

Plans for the 0.2 release (this week)

[Carl Worth]

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>

[notmuch] [PATCH] Prevent data loss caused by SIGINT during notmuch new

[Carl Worth]

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] Fix typo in notmuch.h documentation regarding database open modes

[Carl Worth]

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] Add count command to manual page

[Carl Worth]

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] json_quote_str should handle non-ASCII characters

[Carl Worth]

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

[Carl Worth]

On Sat, 13 Mar 2010 16:27:57 -0500, James Westby <jw+debian at jameswestby.net> 
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>

[PATCH] emacs: Add notmuch-hello.el, a friendly frontend to notmuch

[David Edmondson]

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

[Xavier Maillard]

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

[Tomas Carnecky]

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] Add compat version of strcasestr

[Tomas Carnecky]

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

[Dirk Hohndel]

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

Use of strcasestr

[Tomas Carnecky]

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

Use of strcasestr

[Mikhail Gusarov]

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>

[PATCH] notmuch new --new-tags=tags...

[Anthony Towns]

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 

Re: [PATCH] emacs: Add notmuch-hello.el, a friendly frontend to notmuch

[Michal Sojka]

On Mon, 12 Apr 2010, David Edmondson wrote:
 commit e55dc251b9e8001fe16873fadac565563e606d69
 Author: David Edmondson d...@dme.org
 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

[David Edmondson]

On Tue, 13 Apr 2010 12:25:43 +0200, Michal Sojka sojk...@fel.cvut.cz 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

[Dirk Hohndel]

On Tue, 13 Apr 2010 15:59:24 +1000, Anthony Towns a...@erisian.com.au wrote:
 On Tue, Apr 13, 2010 at 14:10, Dirk Hohndel hohn...@infradead.org 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.

[Servilio Afre Puentes]

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 servi...@gmail.com
---
 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.

[Servilio Afre Puentes]

Signed-off-by: Servilio Afre Puentes servi...@gmail.com
---
 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

[Carl Worth]

On Sat, 13 Mar 2010 16:27:57 -0500, James Westby jw+deb...@jameswestby.net 
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] Prevent data loss caused by SIGINT during notmuch new

[Carl Worth]

On Tue, 30 Mar 2010 10:23:23 +0200, Michal Sojka sojk...@fel.cvut.cz 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 sojk...@fel.cvut.cz

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: Plans for the 0.2 release (this week)

[Carl Worth]

On Thu, 08 Apr 2010 09:47:00 +0200, Sebastian Spaeth sebast...@sspaeth.de 
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)

[Carl Worth]

On Thu, 08 Apr 2010 09:52:21 -0400, Jameson Rollins 
jroll...@finestructure.net 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

[PATCH] First tests for JSON output and UTF-8 in mail body and subject

[Gregor Hoffleit]

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 test_su...@notmuchmail.org, To: Notmuch Test Suite 
test_su...@notmuchmail.org, 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 test_su...@notmuchmail.org, To: Notmuch Test 
Suite test_su...@notmuchmail.org, 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

[Carl Worth]

On Wed,  3 Mar 2010 08:50:56 +0100, Michal Sojka sojk...@fel.cvut.cz 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)

[Carl Worth]

On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth cwo...@cworth.org wrote:
 For the upcoming 0.2 release, here are some things that I would like to
 have in place:
 
   * 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

[Carl Worth]

On Thu, 08 Apr 2010 08:07:48 -0700, Dirk Hohndel hohn...@infradead.org 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 em...@add.res 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 cwo...@localhost; 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 cwo...@localhost (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

[Carl Worth]

On Mon, 12 Apr 2010 10:30:54 +0200, Sebastian Spaeth sebast...@sspaeth.de 
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: [notmuch] [PATCH v2] notmuch.el: add functionality in notmuch search mode to add or remove tags by region

[Carl Worth]

On Fri, 09 Apr 2010 10:11:00 -0400, Jesse Rosenthal jrosent...@jhu.edu 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

[Jesse Rosenthal]

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 cwo...@cworth.org wrote:
 On Fri, 09 Apr 2010 10:11:00 -0400, Jesse Rosenthal jrosent...@jhu.edu 
 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

[Carl Worth]

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

[Dirk Hohndel]

On Tue, 13 Apr 2010 10:37:49 -0700, Carl Worth cwo...@cworth.org wrote:
 On Thu, 08 Apr 2010 08:07:48 -0700, Dirk Hohndel hohn...@infradead.org 
 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 em...@add.res 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 cwo...@localhost; 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 cwo...@localhost (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

[Dirk Hohndel]

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 hohn...@infradead.org
---
 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 strings.h
+
+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 string.h
+
+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 21
+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 EOF
 
 All required packages were found. You may now run the following
@@ -384,6 +395,10 @@ zsh_completion_dir = 
\$(prefix)/share/zsh/functions/Completion/Unix
 # build its own version)
 HAVE_GETLINE = ${have_getline}
 
+# Whether the strcasestr function is available (if not, then notmuch will
+# build its own version)
+HAVE_STRCASESTR = ${have_strcasestr}
+
 # Flags needed to compile and link against Xapian
 XAPIAN_CXXFLAGS = ${xapian_cxxflags}
 XAPIAN_LDFLAGS = ${xapian_ldflags}
@@ -405,9 +420,10 @@ VALGRIND_CFLAGS = ${valgrind_cflags}
 # Combined flags for compiling and linking against all of the above
 CONFIGURE_CFLAGS = -DHAVE_GETLINE=\$(HAVE_GETLINE) \$(GMIME_CFLAGS)  \\
   \$(TALLOC_CFLAGS) -DHAVE_VALGRIND=\$(HAVE_VALGRIND)   \\
-  \$(VALGRIND_CFLAGS)
+  \$(VALGRIND_CFLAGS) -DHAVE_STRCASESTR=\$(HAVE_STRCASESTR)
 CONFIGURE_CXXFLAGS = -DHAVE_GETLINE=\$(HAVE_GETLINE) \$(GMIME_CFLAGS)\\
 \$(TALLOC_CFLAGS) -DHAVE_VALGRIND=\$(HAVE_VALGRIND) \\
-\$(VALGRIND_CFLAGS) \$(XAPIAN_CXXFLAGS)
+\$(VALGRIND_CFLAGS) \$(XAPIAN_CXXFLAGS) \\
+ 

[PATCH] Add simplistic compat implementation for strcasestr

[Dirk Hohndel]

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 hohn...@infradead.org
---
 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 strings.h
+
+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 string.h
+
+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

[Tomas Carnecky]

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 Hohndelhohn...@infradead.org


Tested-by: Tomas Carnecky t...@dbservice.com

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

[Jesse Rosenthal]

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

[Tomas Carnecky]

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

[Dirk Hohndel]

On Tue, 13 Apr 2010 20:47:02 +0200, Tomas Carnecky t...@dbservice.com 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 Hohndelhohn...@infradead.org
 
 Tested-by: Tomas Carnecky t...@dbservice.com
 
 (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

[Stewart Smith]

On Tue, 13 Apr 2010 10:53:12 -0700, Carl Worth cwo...@cworth.org 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 ?

[Xavier Maillard]

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 ?

[James Westby]

On Wed, 14 Apr 2010 00:11:50 +0200, Xavier Maillard x...@gnu.org 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 ?

[Xavier Maillard]

On Tue, 13 Apr 2010 23:19:37 +0100, James Westby jw+deb...@jameswestby.net 
wrote:
 On Wed, 14 Apr 2010 00:11:50 +0200, Xavier Maillard x...@gnu.org 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: See only unread message in a thread ?

[Jameson Rollins]

On Tue, 13 Apr 2010 23:19:37 +0100, James Westby jw+deb...@jameswestby.net 
wrote:
 On Wed, 14 Apr 2010 00:11:50 +0200, Xavier Maillard x...@gnu.org 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