Wrapping up the 0.3 release

2010-04-24 Thread David Edmondson
On Sat, 24 Apr 2010 09:53:17 -0700, Dirk Hohndel  
wrote:
> >   * Reply is now splitting the window
> > 
> > We're copying the original message into the new reply buffer, so
> > what's the advantage of splitting here?
> 
> I'll voice my "don't like" of this feature as well, I guess.

This depends at least somewhat on the setting of `pop-up-windows'. Maybe
we should:

 (let ((pop-up-windows nil))
  ...)

in the reply code?

I think that notmuch window handling generally needs some consideration
and improvement.

> > Finally, any of the tweaks I suggested to notmuch-hello mode would be
> > quite welcome. I might take a whack at some of these.

Hopefully early next week for me.

dme.
-- 
David Edmondson, http://dme.org


Failing test cases

2010-04-24 Thread Dirk Hohndel
On Sun, 25 Apr 2010 10:17:44 +1000, Jason White  wrote:
> I just tried to build the Debian package from the latest Git master branch,
> but this could not be completed due to failures of test cases 067, 068 and
> 069.
> 
> Are others seeing this, or is it a peculiarity of my system (Debian Sid,
> x86-64)?

No, this is the expected behavior right now. Carl has the habit of
committing the tests before he commits the code that addresses the issue
/ feature that is tested for. And it turned out that there was a bug in
the original version of that code. I have submitted a fixed version but
that hasn't been pushed, yet.

0.3 with all the latest and greatest fixes and cleanups should be out,
shortly. 

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


[PATCH 7/7] Integrate notmuch-fcc mechansim

2010-04-24 Thread Dirk Hohndel

On Fri, 23 Apr 2010 11:38:57 +0200, Sebastian Spaeth  
wrote:
> I have gone wild and added a defcustom "notmuch-fcc-dirs".
> Depending on the value of that variable we will not do any
> maildir fcc at all (nil, the default), or it is of the format
> (("defaultsentbox")
>  ("full name " . "Work/sentbox")
>  ("full name2 " . "Work2/sentbox"))

I love this feature (unsurprising, as I was the one who requested it
repeatedly...).

One question from the elisp noop:

> +   (let ((subdir (cdr (assoc (message-fetch-field "from") 
> notmuch-fcc-dirs

Why not make this 

(let ((subdir (cdr (assoc-string (message-fetch-field "from") 
notmuch-fcc-dirs t

and have the association be case insensitive?

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


Wrapping up the 0.3 release

2010-04-24 Thread Dirk Hohndel
On Sat, 24 Apr 2010 15:05:55 -0700, Dirk Hohndel  
wrote:
> > Dirk also mentioned in IRC that there's a regression with the signature
> > being mispositioned before the quoted text with a reply buffer. Now that
> > I've added a signature, I'm noticing this as well.
> 
> Well - we don't seem to be adding the signature ourselves anymore... I
> still don't quite understand where and how we hand over to the existing
> message-mode functions - I why those decide to insert a signature at
> point.

Learning elisp every day. I think I now understand at least somewhat
what's happening there...

> Here's a trivial patch that ALSO adds a signature at the end of the
> message buffer (where it belongs). But I haven't figured out how to get
> rid of the one above the reply...
> 
> diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
> index acb7dbf..493cd0e 100644
> --- a/emacs/notmuch-mua.el
> +++ b/emacs/notmuch-mua.el
> @@ -63,6 +63,7 @@
>  ;; line and then the body.
>  (with-temp-buffer
>(call-process notmuch-command nil t nil "reply" query-string)
> +  (message-insert-signature)
>(goto-char (point-min))
>(if (re-search-forward "^$" nil t)
> (save-excursion

This patch is of course completely bogus. But understanding why it was
bogus helped me come up with this patch, that hopefully makes more
sense. People who ACTUALLY understand elisp - please take a look

(I could have sworn there was a variable somewhere that gives me the
correct regex to search for a signature separator... but I can't find
it. so please replace '-- ' with that if you know)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index acb7dbf..05c9603 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -82,7 +82,13 @@
 (message-hide-headers)
 (save-excursion
   (goto-char (point-max))
-  (insert body))
+  (if (re-search-backward "-- " nil t)
+ (progn 
+   (forward-line -1)
+   (insert body))
+   (progn
+ (goto-char (point-max))
+ (insert body
 (set-buffer-modified-p nil)))

 (defun notmuch-mua-forward-message ()


-- 
Dirk Hohndel
Intel Open Source Technology Center


Wrapping up the 0.3 release

2010-04-24 Thread Dirk Hohndel
On Sat, 24 Apr 2010 14:45:45 -0700, Carl Worth  wrote:
> > It doesn't for me with origin/master. Or let me double check... what do
> > you think would be the correct order (as this is a matter of taste for
> > some people)...
> 
> The order in the reply buffer is fine. But with "m" I get the User-Agent
> first which looks a bit strange.

Yep, same here.

> Dirk also mentioned in IRC that there's a regression with the signature
> being mispositioned before the quoted text with a reply buffer. Now that
> I've added a signature, I'm noticing this as well.

Well - we don't seem to be adding the signature ourselves anymore... I
still don't quite understand where and how we hand over to the existing
message-mode functions - I why those decide to insert a signature at
point.

Here's a trivial patch that ALSO adds a signature at the end of the
message buffer (where it belongs). But I haven't figured out how to get
rid of the one above the reply...

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index acb7dbf..493cd0e 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -63,6 +63,7 @@
 ;; line and then the body.
 (with-temp-buffer
   (call-process notmuch-command nil t nil "reply" query-string)
+  (message-insert-signature)
   (goto-char (point-min))
   (if (re-search-forward "^$" nil t)
  (save-excursion

> > I think we should make this a "requirement" for patches to include a
> > little NEWS blurb and either a test case or an explanation why there
> > isn't a test case...
> 
> I've asked for these, but I haven't been pushing hard on this.

I will start playing the nagger

> Review for some of these simple things would be much appreciated from
> anybody on the list, (and would help ensure that patches are more likely
> to be ready-to-go once I get them). So let's see more of things like
> this from anyone on the list:
> 
>   Looks like a great feature---now it just needs a test case.
> 
>   I've tested this and it does just what I want. Here's a
>   follow-on patch that adds an item to the NEWS file for this.
> 
>   I can't common on the specific logic of the patch, but I did
>   notice some trailing whitespace. You'll want to clean that up
>   and resubmit so the patch won't be rejected.

I can do all of those.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


Wrapping up the 0.3 release

2010-04-24 Thread Carl Worth
On Sat, 24 Apr 2010 09:53:17 -0700, Dirk Hohndel  
wrote:
> On Sat, 24 Apr 2010 08:37:11 -0700, Carl Worth  wrote:
>
> I sent a patch last night - but it's not realtive to the last thing that
> I sent, instead relative to last night's master. Do you want me to
> create another one?

No, what you sent last night is perfect. That will be easier for me.

> It doesn't for me with origin/master. Or let me double check... what do
> you think would be the correct order (as this is a matter of taste for
> some people)...

The order in the reply buffer is fine. But with "m" I get the User-Agent
first which looks a bit strange.

Dirk also mentioned in IRC that there's a regression with the signature
being mispositioned before the quoted text with a reply buffer. Now that
I've added a signature, I'm noticing this as well.

> I think we should make this a "requirement" for patches to include a
> little NEWS blurb and either a test case or an explanation why there
> isn't a test case...

I've asked for these, but I haven't been pushing hard on this.

Review for some of these simple things would be much appreciated from
anybody on the list, (and would help ensure that patches are more likely
to be ready-to-go once I get them). So let's see more of things like
this from anyone on the list:

Looks like a great feature---now it just needs a test case.

I've tested this and it does just what I want. Here's a
follow-on patch that adds an item to the NEWS file for this.

I can't common on the specific logic of the patch, but I did
notice some trailing whitespace. You'll want to clean that up
and resubmit so the patch won't be rejected.

Thanks,

-Carl

-- 
carl.d.worth at intel.com
-- 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/20100424/19746ec2/attachment.pgp>


[notmuch] auto-tagging replied messages

2010-04-24 Thread Carl Worth

-- 
carl.d.worth at intel.com
On Sat, 24 Apr 2010 09:56:04 -0400, Jesse Rosenthal  
wrote:
> I'd love to put this into shape to become part of notmuch proper. 

Great!

> My question, for this and other things I've worked on, is where code
> that targets message-mode should go. In notmuch-mua.el? Or a new
> notmuch-message-utils.el? Or just a catch-all notmuch-utils.el? Once I
> know where it would make the most sense to group these, I'll submit a
> patch.

You can call it notmuch-message.el if you'd like.

I'm never a fan of something generic like -utils. Things like that seem
to grow without bounds.

> But just to clarify: you don't mind if removal is a customizable user
> option, right?

I don't mind at all. I was just happy to realize that we wouldn't have
to do any tag removal to make the feature useful out-of-the-box.

-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/20100424/90699649/attachment.pgp>


[PATCH] Add NEWS updates for my last batch of patches

2010-04-24 Thread micah anderson
On Fri, 23 Apr 2010 10:42:31 -0700, Dirk Hohndel  
wrote:

> +Provide 'G' key binding to trigger mail refresh
> +
> +  The 'G' key works wherever '=' works. Before refreshing the screen
> +  it calls an external program that can be used to poll email servers,
> +  run notmuch new and setup specific tags for the new emails. The
> +  script to be called can be customized with. Use the customize screen

Strange sentence: "The script to be called can be customized with." 

I'd suggest an improvement, but I'm not sure what it should read.

micah


-- 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/20100424/d8151fd3/attachment.pgp>


improve from-header guessing

2010-04-24 Thread Dirk Hohndel
On Fri, 23 Apr 2010 11:47:04 -0700, Carl Worth  wrote:
> On Fri, 16 Apr 2010 13:51:40 -0700, Dirk Hohndel  
> wrote:
> > The following two patches should address most of the concerns raised 
> > to my previous series. 
> 
> Allow me to raise new concerns then. ;-)

Any time

> > The first patch simply adds an interface to obtain a concatenation of
> > all instances of a specific header from an email.
> 
> I was hoping to see the "special-case value of NULL" go away with this
> change.
> 
> And I like that there's a new function to get the concatenated header,
> (I would prefer an unabbreviated name of get_concatenated_header than
> get_header_concat), but I don't like seeing all the existing callers of
> get_header updated to pass an extra 0. Instead, I'd prefer to see those
> calls unchanged, and a tiny new get_header that passes the 0 and then
> make the actual implementing function be static and named something like
> notmuch_message_file_get_header_internal.

Turns out that the way I did this was broken anyway. So we can simply
forget these patches and your concerns. I'm sure you'll raise new
concerns on the new ("rearchitected") patches.

> Both patches have some trailing whitespace. I see these easily wince I
> have the following in my ~/.gitconfig:
> 
>   [core]
>   whitespace = trailing-space,space-before-tab

I know. I'm trying to be better about checking whitespace pollution
before submitting things.

> Finally, I'd like to see some tests for this feature. (But we do have
> the feature already without tests, so I won't strictly block on that).

Hu? You even commited these already. Or am I reading email out of order
again? 

/D


[PATCH 5/5] Simple attempt to display author names in a friendlier way

2010-04-24 Thread Dirk Hohndel
This patch only addresses the typical Outlook/Exchange case
where we have "Last, First"  or
"Last, First MI" .

In the future we should be more fexible as to the formats
we recognize, but for now we address this one as it is the
Exchange default setting and therefore the most common one.

Signed-off-by: Dirk Hohndel 
---
 lib/thread.cc |   51 +--
 1 files changed, 49 insertions(+), 2 deletions(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index c80bb26..b8be3e1 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -147,6 +147,51 @@ _thread_move_matched_author (notmuch_thread_t *thread,
 return;
 }

+/* clean up the uggly "Lastname, Firstname" format that some mail systems
+ * (most notably, Exchange) are creating to be "Firstname Lastname"
+ * To make sure that we don't change other potential situations where a
+ * comma is in the name, we check that we match one of these patterns
+ * "Last, First" 
+ * "Last, First MI" 
+ */
+char *
+_thread_cleanup_author (notmuch_thread_t *thread,
+   const char *author, const char *from)
+{
+char *clean_author,*test_author;
+const char *comma;
+char *blank;
+int fname,lname;
+
+clean_author = talloc_strdup(thread, author);
+if (clean_author == NULL)
+   return NULL;
+comma = strchr(author,',');
+if (comma) {
+   /* let's assemble what we think is the correct name */
+   lname = comma - author;
+   fname = strlen(author) - lname - 2;
+   strncpy(clean_author, comma + 2, fname);
+   *(clean_author+fname) = ' ';
+   strncpy(clean_author + fname + 1, author, lname);
+   *(clean_author+fname+1+lname) = '\0';
+   /* make a temporary copy and see if it matches the email */
+   test_author = talloc_strdup(thread,clean_author);
+
+   blank=strchr(test_author,' ');
+   while (blank != NULL) {
+   *blank = '.';
+   blank=strchr(test_author,' ');
+   }
+   if (strcasestr(from, test_author) == NULL)
+   /* we didn't identify this as part of the email address
+   * so let's punt and return the original author */
+   strcpy (clean_author, author);
+
+}
+return clean_author;
+}
+
 /* Add 'message' as a message that belongs to 'thread'.
  *
  * The 'thread' will talloc_steal the 'message' and hold onto a
@@ -161,6 +206,7 @@ _thread_add_message (notmuch_thread_t *thread,
 InternetAddressList *list = NULL;
 InternetAddress *address;
 const char *from, *author;
+char *clean_author;

 _notmuch_message_list_add_message (thread->message_list,
   talloc_steal (thread, message));
@@ -183,8 +229,9 @@ _thread_add_message (notmuch_thread_t *thread,
mailbox = INTERNET_ADDRESS_MAILBOX (address);
author = internet_address_mailbox_get_addr (mailbox);
}
-   _thread_add_author (thread, author);
-   notmuch_message_set_author (message, author);
+   clean_author = _thread_cleanup_author (thread, author, from);
+   _thread_add_author (thread, clean_author);
+   notmuch_message_set_author (message, clean_author);
}
g_object_unref (G_OBJECT (list));
 }
-- 
1.6.6.1



[PATCH 4/5] Add tests for author name reordering in search results

2010-04-24 Thread Dirk Hohndel
This should be required for all patches :-)

Signed-off-by: Dirk Hohndel 
---
 test/notmuch-test |   28 +++-
 1 files changed, 27 insertions(+), 1 deletions(-)

diff --git a/test/notmuch-test b/test/notmuch-test
index 7082344..f455232 100755
--- a/test/notmuch-test
+++ b/test/notmuch-test
@@ -867,6 +867,33 @@ printf " Searching returns all three messages in one 
thread..."
 output=$($NOTMUCH search foo | notmuch_search_sanitize)
 pass_if_equal "$output" "thread:XXX   2000-01-01 [3/3] Notmuch Test Suite; 
brokenthreadtest (inbox unread)"

+printf "\nTesting author reordering;\n"
+printf " Adding parent message...\t\t\t"
+generate_message [body]=findme [id]=new-parent-id 
[subject]=author-reorder-threadtest '[from]="User "' 
'[date]="Sat, 01 Jan 2000 12:00:00 -"'
+output=$(NOTMUCH_NEW)
+pass_if_equal "$output" "Added 1 new message to the database."
+printf " Adding initial child message...\t\t"
+generate_message [body]=findme '[in-reply-to]=\' 
[subject]=author-reorder-threadtest '[from]="User1 "' 
'[date]="Sat, 01 Jan 2000 12:00:00 -"'
+output=$(NOTMUCH_NEW)
+pass_if_equal "$output" "Added 1 new message to the database."
+printf " Adding second child message...\t\t\t"
+generate_message [body]=findme '[in-reply-to]=\' 
[subject]=author-reorder-threadtest '[from]="User2 "' 
'[date]="Sat, 01 Jan 2000 12:00:00 -"'
+output=$(NOTMUCH_NEW)
+pass_if_equal "$output" "Added 1 new message to the database."
+printf " Searching when all three messages match...\t"
+output=$($NOTMUCH search findme | notmuch_search_sanitize)
+pass_if_equal "$output" "thread:XXX   2000-01-01 [3/3] User, User1, User2; 
author-reorder-threadtest (inbox unread)"
+printf " Searching when two messages match...\t\t"
+output=$($NOTMUCH search User1 or User2 | notmuch_search_sanitize)
+pass_if_equal "$output" "thread:XXX   2000-01-01 [2/3] User1, User2| User; 
author-reorder-threadtest (inbox unread)"
+printf " Searching when only one message matches...\t"
+output=$($NOTMUCH search User2 | notmuch_search_sanitize)
+pass_if_equal "$output" "thread:XXX   2000-01-01 [1/3] User2| User, User1; 
author-reorder-threadtest (inbox unread)"
+printf " Searching when only first message matches...\t"
+output=$($NOTMUCH search User | notmuch_search_sanitize)
+pass_if_equal "$output" "thread:XXX   2000-01-01 [1/3] User| User1, User2; 
author-reorder-threadtest (inbox unread)"
+
+printf "\nTesting From line heuristics;\n"
 printf " Magic from guessing (nothing to go on)...\t"
 add_message '[from]="Sender "' \
  [to]=mailinglist at notmuchmail.org \
@@ -965,7 +992,6 @@ References: <${gen_msg_id}>
 On Tue, 05 Jan 2010 15:43:56 -0800, Sender  wrote:
 > from guessing test"

-
 echo ""
 echo "Notmuch test suite complete."

-- 
1.6.6.1



[PATCH 3/5] Add NEWS section for author reordering

2010-04-24 Thread Dirk Hohndel
This should be required in all patches

Signed-off-by: Dirk Hohndel 
---
 NEWS |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/NEWS b/NEWS
index eba0fd5..c2057c2 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,13 @@
+
+Visualization of author names that match a search
+
+  When notmuch displays threads as the result of a search, it now
+  lists the authors that match the search before listing the other
+  authors in the thread. It inserts a pipe '|' symbol between the last
+  matching and first non-matching author. This is especially useful in
+  a search that includes tag:unread. Now the authors of the unread
+  messages in the thread are listed first.
+
 Notmuch 0.2 (2010-04-16)
 
 This is the second release of the notmuch mail system, with actual
-- 
1.6.6.1



[PATCH 2/5] Reorder displayed names of thread authors

2010-04-24 Thread Dirk Hohndel
When displaying threads as result of a search it makes sense to list those
authors first who match the search. The matching authors are separated from the
non-matching ones with a '|' instead of a ','

Imagine the default "+inbox" query. Those mails in the thread that
match the query are actually "new" (whatever that means). And some
people seem to think that it would be much better to see those author
names first. For example, imagine a long and drawn out thread that once
was started by me; you have long read the older part of the thread and
removed the inbox tag. Whenever a new email comes in on this thread,
prior to this patch the author column in the search display will first show
"Dirk Hohndel" - I think it should first show the actual author(s) of the new
mail(s).

Signed-off-by: Dirk Hohndel 
---
 lib/thread.cc |   77 +
 1 files changed, 77 insertions(+), 0 deletions(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index e1da060..c80bb26 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -32,6 +32,7 @@ struct _notmuch_thread {
 char *subject;
 GHashTable *authors_hash;
 char *authors;
+char *nonmatched_authors;
 GHashTable *tags;

 notmuch_message_list_t *message_list;
@@ -73,6 +74,79 @@ _thread_add_author (notmuch_thread_t *thread,
thread->authors = talloc_strdup (thread, author);
 }

+/*
+ * move authors of matched messages in the thread to
+ * the front of the authors list, but keep them in
+ * existing order within their group
+ */
+static void
+_thread_move_matched_author (notmuch_thread_t *thread,
+const char *author)
+{
+char *authors_copy;
+char *current_author;
+char *last_pipe,*next_pipe;
+int idx,nm_start,author_len,authors_len;
+
+if (thread->authors == NULL || author == NULL)
+   return;
+if (thread->nonmatched_authors == NULL)
+   thread->nonmatched_authors = thread->authors;
+author_len = strlen(author);
+authors_len = strlen(thread->authors);
+if (author_len == authors_len) {
+   /* just one author */
+   thread->nonmatched_authors += author_len;
+   return;
+}
+current_author = strcasestr(thread->authors, author);
+if (current_author == NULL)
+   return;
+/* how far inside the nonmatched authors is our author? */
+idx = current_author - thread->nonmatched_authors;
+if (idx < 0) {
+   /* already among matched authors */
+   return;
+}
+/* are there any authors in the list after our author? */
+if (thread->nonmatched_authors + author_len < thread->authors + 
authors_len) {
+   /* we have to make changes, so let's get a temp copy */
+   authors_copy = talloc_strdup(thread,thread->authors);
+   /* nm_start is the offset into where the non-matched authors start */
+   nm_start = thread->nonmatched_authors - thread->authors;
+   /* copy this author and add the "| " - the if clause above tells us 
there's more */
+   strncpy(thread->nonmatched_authors,author,author_len);
+   strncpy(thread->nonmatched_authors+author_len,"| ",2);
+   thread->nonmatched_authors += author_len+2;
+   if (idx > 0) {
+ /* we are actually moving authors around, not just changing the 
separator
+  * first copy the authors that came BEFORE our author */
+ strncpy(thread->nonmatched_authors, authors_copy+nm_start, idx-2);
+ /* finally, if there are authors AFTER our author, copy those */
+ if(author_len+nm_start+idx < authors_len) {
+   strncpy(thread->nonmatched_authors + idx - 2,", ",2);
+   strncpy(thread->nonmatched_authors + idx, authors_copy+nm_start + 
idx + author_len + 2,
+   authors_len - (nm_start + idx + author_len + 2));
+ }
+   }
+   /* finally let's make sure there's just one '|' in the authors string */
+   last_pipe = strchr(thread->authors,'|');
+   while (last_pipe) {
+   next_pipe = strchr(last_pipe+1,'|');
+   if (next_pipe)
+   *last_pipe = ',';
+   last_pipe = next_pipe;
+   }
+} else {
+   thread->nonmatched_authors += author_len;
+   /* so now all authors are matched - let's remove the '|' */
+   last_pipe = strchr(thread->authors,'|');
+   if (last_pipe)
+   *last_pipe = ',';
+}
+return;
+}
+
 /* Add 'message' as a message that belongs to 'thread'.
  *
  * The 'thread' will talloc_steal the 'message' and hold onto a
@@ -110,6 +184,7 @@ _thread_add_message (notmuch_thread_t *thread,
author = internet_address_mailbox_get_addr (mailbox);
}
_thread_add_author (thread, author);
+   notmuch_message_set_author (message, author);
}
g_object_unref (G_OBJECT (list));
 }
@@ -182,6 +257,7 @@ _thread_add_matched_message (notmuch_thread_t *thread,
notmuch_message_set_flag (hashed_message,

[PATCH 1/5] Add authors member to message

2010-04-24 Thread Dirk Hohndel
message->authors contains the author's name (as we want to print it)
get / set methods are declared in notmuch-private.h

Signed-off-by: Dirk Hohndel 
---
 lib/message.cc|   18 ++
 lib/notmuch-private.h |   10 ++
 2 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/lib/message.cc b/lib/message.cc
index 721c9a6..4b2f98f 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -35,6 +35,7 @@ struct _notmuch_message {
 char *thread_id;
 char *in_reply_to;
 char *filename;
+char *author;
 notmuch_message_file_t *message_file;
 notmuch_message_list_t *replies;
 unsigned long flags;
@@ -110,6 +111,7 @@ _notmuch_message_create (const void *talloc_owner,
 message->in_reply_to = NULL;
 message->filename = NULL;
 message->message_file = NULL;
+message->author = NULL;

 message->replies = _notmuch_message_list_create (message);
 if (unlikely (message->replies == NULL)) {
@@ -533,6 +535,22 @@ notmuch_message_get_tags (notmuch_message_t *message)
 return _notmuch_convert_tags(message, i, end);
 }

+const char *
+notmuch_message_get_author (notmuch_message_t *message)
+{
+return message->author;
+}
+
+void
+notmuch_message_set_author (notmuch_message_t *message,
+   const char *author)
+{
+if (message->author)
+   talloc_free(message->author);
+message->author = talloc_strdup(message, author);
+return;
+}
+
 void
 _notmuch_message_set_date (notmuch_message_t *message,
   const char *date)
diff --git a/lib/notmuch-private.h b/lib/notmuch-private.h
index 94cce1b..6e83cc3 100644
--- a/lib/notmuch-private.h
+++ b/lib/notmuch-private.h
@@ -275,6 +275,16 @@ _notmuch_message_talloc_copy_data (notmuch_message_t 
*message);
 void
 _notmuch_message_clear_data (notmuch_message_t *message);

+/* Set the author member of 'message' - this is the representation used
+ * when displaying the message */
+void
+notmuch_message_set_author (notmuch_message_t *message, const char *author);
+
+/* Get the author member of 'message' */
+const char *
+notmuch_message_get_author (notmuch_message_t *message);
+
+
 /* index.cc */

 notmuch_status_t
-- 
1.6.6.1



new patch series for author reordering code

2010-04-24 Thread Dirk Hohndel

I tried to break this out into logically independent pieces - but to connect
this as a series.  
First we add the authors member and accessors to message
Second the reordering of thread authors (still the original string based
algorithm that I used before - I couldn't quite make sense of cworth's proposed
algorithm
Third a NEWS blurb
Fourth test for the new functionality
Fifth a first simple routine to make author names easier to read - this one
undoes the typical Exchange ugliness

I think this could go into 0.3 as is. I've been using the mostly identical
previous version for about a week - the changes here are mostly cleanup based
on cworth's feedback.

I am planning to enhance the "display author names in a friendlier way" feature
in the future, capturing more cases.

/D



[PATCH] notmuch.pod: pod version of documentation, converted by rman, massaged by hand.

2010-04-24 Thread David Bremner
On Thu, 31 Dec 2009 13:39:29 -0400, david at tethera.net wrote:
> 
> The idea here is to be able to generate the online help and the man page from 
> one source.
> 
> To generate a man page:
>
>pod2man notmuch.pod > notmuch.1
> 
> To generate help for a specific notmuch subcommand
> 
>podselect -section 'Commands/subcommand.*' notmuch.pod | pod2text -c
> 

As I'm faced with writing docs for output selection, I'd like to revisit
this idea. I didn't get any feedback, positive or negative about the
idea of keeping the docs in pod.  I don't care much about the format,
but I think it would be nice to avoid maintaining two copies of the
documentation.

Should I rebase/rebuild this against the current docs, or not bother?

d


[PATCH] Reordering of thread authors to list matching authors first

2010-04-24 Thread Dirk Hohndel
On Fri, 23 Apr 2010 17:21:53 -0700, Carl Worth  wrote:
> On Wed, 21 Apr 2010 20:58:27 -0700, Dirk Hohndel  
> wrote:
> > When displaying threads as result of a search it makes sense to list those
> > authors first who match the search. The matching authors are separated from 
> > the
> > non-matching ones with a '|' instead of a ','
> 
> It seems a reasonable feature to me.

I switched back to origin/master to help get ready for 0.3 and
tremendously miss this feature :-) 

> Some notes on the patch:
> 
> > +void
> > +notmuch_message_set_author (notmuch_message_t *message,
> > +   const char *author)
> > +{
> > +message->author = talloc_strdup(message, author);
> > +return;
> > +}
> 
> This is leaking any previously set author value, (admittedly, it's only
> a "talloc leak" so it will still get cleaned up when the message is
> cleaned up, but still.

Fixed in forthcoming revision of this patch

> 
> > +/* Set the author member of 'message' - this is the representation used
> > + * when displaying the message
> > + */
> > +void
> > +notmuch_message_set_author (notmuch_message_t *message, const char 
> > *author);
> > +
> > +/* Get the author member of 'message'
> > + */
> > +const char *
> > +notmuch_message_get_author (notmuch_message_t *message);
> 
> The notmuch.h file is our publicly installed header file for the library
> interface. I don't think the feature here requires any new library
> interface. Even if it did, we wouldn't want a public function like
> set_author that could simply scramble internal state and change the
> result of future calls to get_author.

My mistake - moved them to notmuch-private.h

> > +/*
> > + * move authors of matched messages in the thread to 
> > + * the front of the authors list, but keep them in
> > + * existing order within their group
> > + */
> > +static void
> > +_thread_move_matched_author (notmuch_thread_t *thread,
> > +const char *author)
> 
> The implementation here seems a bit fiddly.
> 
> We already have two passes over the messages, (first all messages, and
> then all matched messages). And we're currently calling add_author from
> the first pass.
> 
> How about simply calling a new add_matched_author from the second pass
> which would look very much like the existing add_author. Then we could
> change add_author to accumulate authors into an array rather than a
> string. Then, finally, we would append any of these authors not already
> in the matched_authors hash tabled onto the final string.
> 
> That should be less code and easier to understand I think.
> 
> I can take a whack at that later if you don't beat me to it.

Maybe I'm misunderstanding your proposed algorithm - but it seems quite
a bit more complicated than what I'm doing today...

/D


[PATCH] emacs: Fix i-search to open up invisible citations as necessary

2010-04-24 Thread Dirk Hohndel
On Sat, 24 Apr 2010 07:42:48 -0700, Carl Worth  wrote:
> On Fri, 23 Apr 2010 18:39:33 +0100, David Edmondson  wrote:
> > Add an `isearch-open-invisible' property to the overlays used to hide
> > citations and signatures, together with an appropriate function to
> > leave the invisible text visible should that be required.
> 
> This is a fantastic feature, David. Thanks! This is pushed.
> 
> I knew emacs could do this kind of thing, and I had even tried to
> implement it once, but I hadn't succeeded for some reason.
> 
> Next, I wonder if we shouldn't do something similar for the search
> view. It might be quite handy if all authors and all unique subjects for
> a thread were made available for i-search in the buffer, but hidden by
> default and expanded as needed like this. What do you think?

I would love this

/D


[PATCH] Clean up author display for some "Last, First" cases

2010-04-24 Thread Dirk Hohndel
On Sat, 24 Apr 2010 08:30:22 -0700, Carl Worth  wrote:
> On Wed, 21 Apr 2010 22:04:39 -0700, Dirk Hohndel  
> wrote:
> > +/* clean up the uggly "Lastname, Firstname" format that some mail systems
> > + * (most notably, Exchange) are creating to be "Firstname Lastname" 
> > + * To make sure that we don't change other potential situations where a 
> > + * comma is in the name, we check that we match one of these patterns
> > + * "Last, First" 
> > + * "Last, First MI" 
> 
> This is an interesting idea. We could make it a little more flexible by
> doing a regexp comparison of "first.*last" against the email address,
> (perhaps people have email addresses like carl_worth at example.com?)

I'll look into that. We actually had some discussion about this on IRC
and I was thinking of taking this feature to a new level... something
like: 
- by default we show names as they come in (least surprise)
- we offer to reverse Last, First
- we offer to shorten to FirstL
- we offer an alias map
So I could define that mail from "cworth at cworth.org" gets the author
listed as "cworth". Or as CarlW.

> > +char *cleanauthor,*testauthor;
> 
> I'd much rather see an underscore separating two words in a single
> identifier, (so clean_author, test_author).

Happy to comply to your preferences in the future

> > +   /* let's assemble what we think is the correct name */
> > +   lname = comma - author;
> > +   fname = strlen(author) - lname - 2;
> > +   strncpy(cleanauthor, comma + 2, fname);
> > +   *(cleanauthor+fname) = ' ';
> > +   strncpy(cleanauthor + fname + 1, author, lname);
> > +   *(cleanauthor+fname+1+lname) = '\0';
> 
> The comment above, ("what we think is the correct name"), didn't help me
> understand what the code is doing. And the code is hard enough to follow
> that I could really use some help. Something like:
> 
> /* Break at comma and reverse: "Last, First etc." -> "First Last etc." */

Ok, I'll try to be more explicit in documenting algorithms

> Lots of little additions here and there so plenty of chance for an
> off-by-one. Do we have a test case for this yet?

Nope. Will do.

> > +   /* make a temporary copy and see if it matches the email */
> > +   testauthor = xstrdup(cleanauthor);
> 
> It would be preferable to use talloc functions consistently. (Existing
> occurrences of xstrdup in the code base are for the sake of
> talloc-unfriendly glib data structures like GHashTable.)
> 
> As is, testauthor is leaking.

Oops.

/D


[notmuch] auto-tagging replied messages

2010-04-24 Thread Jesse Rosenthal
On Sat, 24 Apr 2010 05:38:36 -0700, Carl Worth  wrote:
> So here's my vote for someone cleaning this up into a patch that could
> be applied directly to notmuch rather than just being a snippet of code
> to shove into .emacs.

I'd love to put this into shape to become part of notmuch proper. 

My question, for this and other things I've worked on, is where code
that targets message-mode should go. In notmuch-mua.el? Or a new
notmuch-message-utils.el? Or just a catch-all notmuch-utils.el? Once I
know where it would make the most sense to group these, I'll submit a
patch.

> Supporting the removal of a tag as well is clever, but I wouldn't
> suggest doing that by default (the patch doesn't anyway). And instead,
> people could do things like searches for "tag:reply-required and not
> tag:replied".

But just to clarify: you don't mind if removal is a customizable user
option, right?

Best,
Jesse


Wrapping up the 0.3 release

2010-04-24 Thread Dirk Hohndel

On Sat, 24 Apr 2010 08:37:11 -0700, Carl Worth  wrote:
> I pushed hard to get most everything we wanted for 0.3 done yesterday,
> (which was one week since 0.2). I think we're still within the tolerance
> of my published "about a week" schedule, but I would like to wrap things
> up soon.
> 
> Here are the features that I still have left in my queue at this point:
> 
>   * improve from-header guessing
> 
> Dirk is looking into fixing a segfault found by the test suite here

I sent a patch last night - but it's not realtive to the last thing that
I sent, instead relative to last night's master. Do you want me to
create another one?

Basically, the way I was trying to do concatenation of Received headers
earlier was fundamentally broken - it made assumptions about being able
to continue reading the headers even after we closed the file already.

Not so good.

>   * Fcc, Maildir, and Emacs message-mode -- a bit of code
> 
> This is next on my list to apply. Thanks for the extra testing!
> 
> There are a few other features that people had proposed but that didn't
> pass review yet. If people follow-up with those quickly, they can still
> go in. Otherwise, there's another new merge window coming up soon!

I'll be working on notmuch for the next few hours and once my git trees
are straightened out again, I'll look into what's missing from my wish
list

> Meanwhile, I'm aware of two regressions I'd like to see fixed before
> 0.3:
> 
>   * Reply is now splitting the window
> 
> We're copying the original message into the new reply buffer, so
> what's the advantage of splitting here?

I'll voice my "don't like" of this feature as well, I guess.

>   * Composing a new message with 'm' brings up headers in a scrambled
> order.
> 
> A minor point, but it would be nice to fix this.

It doesn't for me with origin/master. Or let me double check... what do
you think would be the correct order (as this is a matter of taste for
some people)...

> Finally, any of the tweaks I suggested to notmuch-hello mode would be
> quite welcome. I might take a whack at some of these.
> 
> Then, there's the task of writing up NEWS. Dirk started helping with
> that, which I appreciate. If anyone else wants to write up descriptions
> of their favorite features that have been merged, that would be great.

I think we should make this a "requirement" for patches to include a
little NEWS blurb and either a test case or an explanation why there
isn't a test case...

/D


[PATCH] removed unused variables

2010-04-24 Thread Dirk Hohndel
On Fri, 23 Apr 2010 17:55:09 -0700, Carl Worth  wrote:
> On Thu, 22 Apr 2010 20:26:46 -0700, Dirk Hohndel  
> wrote:
> > 
> > trivial compiler warning fix
> 
> Thanks. I finally caught up to this.
> 
> I had seen this patch from you earlier, when I didn't have a convenient
> working-directory for just applying it---so I've been religiously
> ignoring those warnings ever since rather than just fixing them. ;-)

This is something that I got caught in last night. I have brought in
more patches from others, worked on my own patches, and suddenly I
got stuck in git-branch-hell and couldn't figure out how to move changes
from one branch to another. That's why my reply-guessing-segfault fix is
not relative to my last patch...

I'm trying to clean up my mess this morning :-)

/D


[PATCH 3/3] notmuch-show.c: control which headers are show for json output.

2010-04-24 Thread da...@tethera.net
From: David Bremner 

This commit adds argument handling from and callbacks to
notmuch-output.c to determine what headers to show in json output.
This requires passing a pointer to a struct containing the output
parameters into several functions, and in particular changes the type of
the function pointers in the show_format structure.
---
 notmuch-show.c |   81 ++--
 1 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/notmuch-show.c b/notmuch-show.c
index 6aa9072..29e2819 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -19,6 +19,7 @@
  */

 #include "notmuch-client.h"
+#include "notmuch-output.h"

 typedef struct show_format {
 const char *message_set_start;
@@ -28,6 +29,7 @@ typedef struct show_format {
 int indent);
 const char *header_start;
 void (*header) (const void *ctx,
+   notmuch_output_options_t *output_opts,
notmuch_message_t *message);
 const char *header_end;
 const char *body_start;
@@ -45,6 +47,7 @@ format_message_text (unused (const void *ctx),
 int indent);
 static void
 format_headers_text (const void *ctx,
+notmuch_output_options_t *opts,
 notmuch_message_t *message);
 static void
 format_part_text (GMimeObject *part,
@@ -64,6 +67,7 @@ format_message_json (const void *ctx,
 unused (int indent));
 static void
 format_headers_json (const void *ctx,
+unused (notmuch_output_options_t *opts),
 notmuch_message_t *message);
 static void
 format_part_json (GMimeObject *part,
@@ -164,7 +168,9 @@ format_message_json (const void *ctx, notmuch_message_t 
*message, unused (int in
 }

 static void
-format_headers_text (const void *ctx, notmuch_message_t *message)
+format_headers_text (const void *ctx,
+unused (notmuch_output_options_t *opts),
+notmuch_message_t *message)
 {
 const char *headers[] = {
"Subject", "From", "To", "Cc", "Bcc", "Date"
@@ -183,28 +189,38 @@ format_headers_text (const void *ctx, notmuch_message_t 
*message)
 }

 static void
-format_headers_json (const void *ctx, notmuch_message_t *message)
+format_headers_json (const void *ctx,
+notmuch_output_options_t *output_opts,
+notmuch_message_t *message)
 {
-const char *headers[] = {
-   "Subject", "From", "To", "Cc", "Bcc", "Date"
+const struct { const char *name; notmuch_output_t key; } headers[] = {
+   { "Subject", NOTMUCH_OUTPUT_SUBJECT},
+   { "From", NOTMUCH_OUTPUT_FROM},
+   { "To", NOTMUCH_OUTPUT_TO},
+   { "Cc", NOTMUCH_OUTPUT_TO},
+   { "Bcc", NOTMUCH_OUTPUT_BCC },
+   { "Date",   NOTMUCH_OUTPUT_DATE}
 };
+
 const char *name, *value;
 unsigned int i;
 int first_header = 1;
 void *ctx_quote = talloc_new (ctx);

 for (i = 0; i < ARRAY_SIZE (headers); i++) {
-   name = headers[i];
-   value = notmuch_message_get_header (message, name);
-   if (value)
-   {
-   if (!first_header)
-   fputs (", ", stdout);
-   first_header = 0;
-
-   printf ("%s: %s",
-   json_quote_str (ctx_quote, name),
-   json_quote_str (ctx_quote, value));
+   if (output_get_flag(output_opts,headers[i].key)) {
+   name = headers[i].name;
+   value = notmuch_message_get_header (message, name);
+   if (value)
+   {
+   if (!first_header)
+   fputs (", ", stdout);
+   first_header = 0;
+
+   printf ("%s: %s",
+   json_quote_str (ctx_quote, name),
+   json_quote_str (ctx_quote, value));
+   }
}
 }

@@ -337,7 +353,9 @@ format_part_json (GMimeObject *part, int *part_count)
 }

 static void
-show_message (void *ctx, const show_format_t *format, notmuch_message_t 
*message, int indent)
+show_message (void *ctx, const show_format_t *format,
+ notmuch_output_options_t *output_options,
+ notmuch_message_t *message, int indent)
 {
 fputs (format->message_start, stdout);
 if (format->message)
@@ -345,20 +363,24 @@ show_message (void *ctx, const show_format_t *format, 
notmuch_message_t *message

 fputs (format->header_start, stdout);
 if (format->header)
-   format->header(ctx, message);
+   format->header(ctx, output_options, message);
 fputs (format->header_end, stdout);

-fputs (format->body_start, stdout);
-if (format->part)
-   show_message_body (notmuch_message_get_filename (message), 
format->part);
-fputs (format->body_end, stdout);
+if (output_get_flag(output_options, NOTMUCH_OUTPUT_BODY)){
+   fputs (format->body_start, stdout);
+   if (format->part)
+   show_message_body (notmuch_message_get_filename (message), 

[PATCH 2/3] notmuch-output.[ch]: initial implementation of output selection argument handling.

2010-04-24 Thread da...@tethera.net
From: David Bremner 

These two files provide a more or less "object oriented" approach to
parsing output selection arguments.  The use of a struct to track
which output pieces are selected is intended to hide the
implementation, which currently uses bitmasks.
---
 Makefile.local   |1 +
 notmuch-output.c |   95 ++
 notmuch-output.h |   49 
 3 files changed, 145 insertions(+), 0 deletions(-)
 create mode 100644 notmuch-output.c
 create mode 100644 notmuch-output.h

diff --git a/Makefile.local b/Makefile.local
index 5bb570b..eb78679 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -240,6 +240,7 @@ notmuch_client_srcs =   \
notmuch-count.c \
notmuch-dump.c  \
notmuch-new.c   \
+   notmuch-output.c\
notmuch-reply.c \
notmuch-restore.c   \
notmuch-search.c\
diff --git a/notmuch-output.c b/notmuch-output.c
new file mode 100644
index 000..a84bbe1
--- /dev/null
+++ b/notmuch-output.c
@@ -0,0 +1,95 @@
+/* notmuch-output.h --- encapsulate handling of output selection.
+ *
+ * Copyright 2010 ?? David Bremner
+ *
+ * This file is part of Notmuch.
+ *
+ * Notmuch 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, either version 3 of the License, or (at
+ * your option) any later version.
+ *
+ * Notmuch 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 Notmuch.  If not, see .
+ *
+ * Authors: David Bremner 
+ */
+
+#include "notmuch-client.h"
+#include "notmuch-output.h"
+
+notmuch_output_options_t *
+output_init(void *ctx){
+notmuch_output_options_t *output_opts;
+
+output_opts = talloc (ctx, notmuch_output_options_t);
+output_opts->output_all=TRUE;
+output_opts->mask=0;
+return output_opts;
+}
+
+int
+output_parse_arg(notmuch_output_options_t *output_opts, const char *arg){
+
+char *opt;
+
+struct { const char *name; notmuch_output_t key; } parse_try[]={
+  {"bcc", NOTMUCH_OUTPUT_BCC},
+  {"body", NOTMUCH_OUTPUT_BODY},
+  {"cc", NOTMUCH_OUTPUT_CC},
+  {"date",NOTMUCH_OUTPUT_DATE},
+  {"from",NOTMUCH_OUTPUT_FROM},
+  {"message-id",NOTMUCH_OUTPUT_MESSAGE_ID},
+  {"subject",NOTMUCH_OUTPUT_SUBJECT},
+  {"to", NOTMUCH_OUTPUT_TO},
+};
+
+opt = strchr(arg, '=');
+if (!opt)
+   return 1;
+
+opt++;
+
+output_opts->output_all=FALSE;
+
+while(opt) {
+   unsigned int i;
+   notmuch_bool_t found = FALSE;
+   notmuch_output_t key = 0;
+
+   for (i = 0; imask |= (1<output_all)
+   return 1;
+
+return (opts->mask & (1<

[PATCH 1/3] remove stale "unused" from around argv and argc in notmuch_show_command.

2010-04-24 Thread da...@tethera.net
From: David Bremner 

In fact argc and argv are used in this function.
---
 notmuch-show.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/notmuch-show.c b/notmuch-show.c
index 26449fa..6aa9072 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -403,7 +403,7 @@ show_messages (void *ctx, const show_format_t *format, 
notmuch_messages_t *messa
 }

 int
-notmuch_show_command (void *ctx, unused (int argc), unused (char *argv[]))
+notmuch_show_command (void *ctx, int argc, char *argv[])
 {
 notmuch_config_t *config;
 notmuch_database_t *notmuch;
-- 
1.7.0



Initial support for selecting what is output

2010-04-24 Thread da...@tethera.net
These are some preliminary patches to add a --output argument to
notmuch show.

notmuch show --format=json --output=from,subject ${query}

or

notmuch show --format=json --output=to,body ${query}

I'd like to implement a bit finer control (to get message-id's only is
not possible right now), and it needs documentation and a test, but I
thought I'd toss this out there to see what people think.



Wrapping up the 0.3 release

2010-04-24 Thread Carl Worth
I pushed hard to get most everything we wanted for 0.3 done yesterday,
(which was one week since 0.2). I think we're still within the tolerance
of my published "about a week" schedule, but I would like to wrap things
up soon.

Here are the features that I still have left in my queue at this point:

  * improve from-header guessing

Dirk is looking into fixing a segfault found by the test suite here

  * Fcc, Maildir, and Emacs message-mode -- a bit of code

This is next on my list to apply. Thanks for the extra testing!

There are a few other features that people had proposed but that didn't
pass review yet. If people follow-up with those quickly, they can still
go in. Otherwise, there's another new merge window coming up soon!

Meanwhile, I'm aware of two regressions I'd like to see fixed before
0.3:

  * Reply is now splitting the window

We're copying the original message into the new reply buffer, so
what's the advantage of splitting here?

  * Composing a new message with 'm' brings up headers in a scrambled
order.

A minor point, but it would be nice to fix this.

Finally, any of the tweaks I suggested to notmuch-hello mode would be
quite welcome. I might take a whack at some of these.

Then, there's the task of writing up NEWS. Dirk started helping with
that, which I appreciate. If anyone else wants to write up descriptions
of their favorite features that have been merged, that would be great.

-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/20100424/a861fa0a/attachment.pgp>


[PATCH] Clean up author display for some "Last, First" cases

2010-04-24 Thread Carl Worth
On Wed, 21 Apr 2010 22:04:39 -0700, Dirk Hohndel  
wrote:
> +/* clean up the uggly "Lastname, Firstname" format that some mail systems
> + * (most notably, Exchange) are creating to be "Firstname Lastname" 
> + * To make sure that we don't change other potential situations where a 
> + * comma is in the name, we check that we match one of these patterns
> + * "Last, First" 
> + * "Last, First MI" 

This is an interesting idea. We could make it a little more flexible by
doing a regexp comparison of "first.*last" against the email address,
(perhaps people have email addresses like carl_worth at example.com?)

> +char *cleanauthor,*testauthor;

I'd much rather see an underscore separating two words in a single
identifier, (so clean_author, test_author).

> + /* let's assemble what we think is the correct name */
> + lname = comma - author;
> + fname = strlen(author) - lname - 2;
> + strncpy(cleanauthor, comma + 2, fname);
> + *(cleanauthor+fname) = ' ';
> + strncpy(cleanauthor + fname + 1, author, lname);
> + *(cleanauthor+fname+1+lname) = '\0';

The comment above, ("what we think is the correct name"), didn't help me
understand what the code is doing. And the code is hard enough to follow
that I could really use some help. Something like:

/* Break at comma and reverse: "Last, First etc." -> "First Last etc." */

Lots of little additions here and there so plenty of chance for an
off-by-one. Do we have a test case for this yet?

> + /* make a temporary copy and see if it matches the email */
> + testauthor = xstrdup(cleanauthor);

It would be preferable to use talloc functions consistently. (Existing
occurrences of xstrdup in the code base are for the sake of
talloc-unfriendly glib data structures like GHashTable.)

As is, testauthor is leaking.

-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/20100424/3d341245/attachment-0001.pgp>


[PATCH] emacs: Add more functions to clean up text/plain parts

2010-04-24 Thread Carl Worth
On Thu, 22 Apr 2010 13:26:06 +0100, David Edmondson  wrote:
> This is a small variant on the previous version of the patch. The
> wrapping of long lines is not enabled by default - it's simply an
> option in the customise interface.

This is really close now. I especially like that the various wash
options are as simple as just checkboxes in the customize
interface. (That might not even be new in this case, but I at least
didn't find it before.)

And that again goes to my point. I don't think we should enable this
washing by default since it can appear as silent corruption to the user,
without any indication that it happened nor how to turn it off.

Notmuch has always done some modification of the message with things
like hiding long citations, etc. But those at least provide
self-documenting buttons on how to make them disappear.

Here's what I see in the customize buffer with the latest patch, along
with some review. Some of this review applies to documentation already
in notmuch---I'm just getting pickier as things appear in
customize because I think we need to hold our documentation there to a
higher standard. (Previously, one would practically have to dive into
the source to find the documentation, and that suggests the reader has
more experience and definitely means the user gsts a lot more context).

Here, I'm trying to review these options from the point of view of a new
user who just started using notmuch, wants to tweak a few things, and is
looking at the customize buffer to figure out what tweaks are possible.

Notmuch Show Hook: 
[X] notmuch-show-pretty-hook
[ ] notmuch-show-turn-off-word-wrap
INS
   State: STANDARD.
   A list of functions called after populating a More

What does "pretty hook" mean? What information would a user need to
determine whether to turn this on or off?

With "turn off word wrap", we have on option to disable wrapping here,
and another option later to turn some wrapping on again. How is a user
expected to figure out which combination of options does what they want?

Notmuch Show Insert Text/Plain Hook: Hide Value
[ ] notmuch-wash-wrap-long-lines
Wrap text in the region whilst maintaining the correct prefix.
[X] notmuch-wash-tidy-citations
Clean up citations.
[X] notmuch-wash-compress-blanks
Compress successive blank lines into one blank line. Remove More
[X] notmuch-wash-markup-citations
Markup citations, and up to one signature in the buffer.

"Tidy", "Clean up", and "Markup" citations are all too vague. What do
each of these actually do?

Also, think about line breaks so that something like "Remove more"
doesn't appear there by default.

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/20100424/4209ef48/attachment.pgp>


[PATCH] emacs: Fix i-search to open up invisible citations as necessary

2010-04-24 Thread Carl Worth
On Fri, 23 Apr 2010 18:39:33 +0100, David Edmondson  wrote:
> Add an `isearch-open-invisible' property to the overlays used to hide
> citations and signatures, together with an appropriate function to
> leave the invisible text visible should that be required.

This is a fantastic feature, David. Thanks! This is pushed.

I knew emacs could do this kind of thing, and I had even tried to
implement it once, but I hadn't succeeded for some reason.

Next, I wonder if we shouldn't do something similar for the search
view. It might be quite handy if all authors and all unique subjects for
a thread were made available for i-search in the buffer, but hidden by
default and expanded as needed like this. What do you think?

-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/20100424/660c87f3/attachment.pgp>


Unhandled Xapian exception

2010-04-24 Thread Carl Worth
On Fri, 23 Apr 2010 13:21:56 +0200, "Sebastian Spaeth"  wrote:
> I propose to try..catch this code block and rather than returning VOID
> it could return NOTMUCH_STATUS_SUCCESS or NOTMUCH_XAPIAN_EXCEPTION.
> Not sure how "notmuch_database_find_message" would notify the caller of
> such an exception situation though. The only possible failure value is
> NULL (which also means did not find such a message).

We haven't been doing fine-grained exception handling in the library so
far. Mostly because the assumption was that there was nothing we could
do---when I first wrote the code I assumed that Xapian exceptions would
be entirely exceptional.

So I just fixed the top-level entry point here to handle this exception
in our standard way, (print the message, then return NULL or
NOTMUCH_STATUS_XAPIAN_EXCEPTION).

While at this, I audited all notmuch_database calls to ensure they
follow this scheme. (I have not yet audited all libnotmuch entry
points.)

Meanwhile, we've recently discovered that there is a Xapian exception
that is not all that exceptional. Since database readers don't lock the
database, it's not hard to have one or more readers accessing the
database when a writer comes along and modifies the database. This
triggers the readers to subsequently fail with a DatabaseModified
exception.

I don't know how conceivable it would be to fix that at the Xapian
level. It might be quite nice if opening a database in read-only mode
gave access to a snapshot of the database as it exists at that time. But
that might be a feature that's entirely unreasonable to implement.

Otherwise, we might want to start supporting more clever handling of the
exception. For example, the high-level application might want to retry
an operation if it fails due to a DatabaseModified exception. To support
this, you would want your python bindings to have a layer that would
catch the C++ exception and re-throw a python exception.

And to support that, we would need a different scheme in the
library. Basically to just document that all calls might throw an
exception and then not catch and print anything. That would at least be
much simpler in the library. Then the top-level "notmuch" application
could just have a C++ wrapper for main() that would catch and print the
exception message.

What do you think?

-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/20100424/cdaf2ca8/attachment.pgp>


notmuch segfault

2010-04-24 Thread Carl Worth
On Fri, 23 Apr 2010 15:26:51 +0200, "Sebastian Spaeth"  wrote:
> It happened again. Both times I had pressed "G" which calls offlineimap
> and which removed messages that the notmuch database still thought are there.

Thanks for the report, Sebastian.

I've just audited all calls to notmuch_message_get_header and tried to
handle NULL in all cases.

Of course, I haven't tested this thoroughly, but we'll hope that things
are better at least.

And perhaps someday someone will hook up some exhaustive
fault-injection-based testing to catch things like this.

-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/20100424/01d989a9/attachment.pgp>


[PATCH] emacs: Re-arrange message sending code

2010-04-24 Thread David Edmondson
On Fri, 23 Apr 2010 13:25:22 -0700, Carl Worth  wrote:
> And I'm hoping that this new support makes it easier for people to hook
> in the Fcc code. Does this mean there's now a single place to add that
> that will make it work for messages composed from 'm', 'f', or 'r'?

Yes.

> The one unpleasantry I've noticed is that in the case of 'm' the headers
> are being put into the buffer in the following order:
> 
>   User-Agent:
>   To:
>   Subject:
>   From:
> 
> where I would prefer them in the following order:
> 
>   From:
>   To:
>   Subject:
>   User-Agent:

I have:

(setq message-hidden-headers
  '("^References:" "^Face:" "^X-Face:" "^X-Draft-From:" "^User-Agent:"))

so the User-Agent is not even visible.

dme.
-- 
David Edmondson, http://dme.org


[PATCH] emacs: Allow headers to be shown by default in show mode

2010-04-24 Thread Carl Worth
On Sat, 24 Apr 2010 05:42:54 -0700, Carl Worth  wrote:
> I think I'll accept the patch, change the default, then remove From from
> the list of headers inserted.

I've done this now.

I've also exported the list of headers to display as another nice
customizable option in "M-x customize-group" "notmuch".

For myself, I removed "Date" from that list too. That gives me a very
compact display without hiding too much information.

I didn't do that by default because several people recently said they'd
prefer to see the actual date rather than the relative date that's in
the summary line. I suppose another possibility would be to remove the
Date header by default and provide an option to display the actual date
in the summary-line instead of the relative date.

Someone that wants that could do that to get one more line of message
content per message displayed.

-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/20100424/dbe20364/attachment.pgp>


[PATCH] emacs: Allow headers to be shown by default in show mode

2010-04-24 Thread Carl Worth
On Fri, 23 Apr 2010 21:08:48 +0100, David Edmondson  wrote:
> I like the current behaviour, but changing the default would be fine.

Which parts of it do you like? Being able to toggle the header back and
forth? Or just that the hidden headers take up so little vertical space?

I think that I would personally like to have the To and Cc headers
visible always. But having From and Date visible as separate rows is
redundant with our current summary bar, (well, Date isn't precisely
redundant).

I think I'll accept the patch, change the default, then remove From from
the list of headers inserted.

-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/20100424/6e42e031/attachment.pgp>


[notmuch] auto-tagging replied messages

2010-04-24 Thread Carl Worth
On Thu, 22 Apr 2010 12:35:16 +0200, "Sebastian Spaeth"  wrote:
> On 2010-03-05, Jesse Rosenthal wrote:
> > One element of traditional clients that I've missed in notmuch is the
> > ability to easily see which messages have been replied to. A look at the
> > thread structure will often make that clear, but for both searching and
> > syncing, an "answered" tag would be nice.
> 
> This patch has been working great so far and is very useful. Can I
> persuade someone to take this into the notmuch code and have a defcustom
> as to which tag a reply should get (or disable if nil)?

I'd like to see the in as well.

Since we name the action of responding to a message "reply" in the
documentation already, my vote for a default tag to add would be
"replied".

Supporting the removal of a tag as well is clever, but I wouldn't
suggest doing that by default (the patch doesn't anyway). And instead,
people could do things like searches for "tag:reply-required and not
tag:replied".

So here's my vote for someone cleaning this up into a patch that could
be applied directly to notmuch rather than just being a snippet of code
to shove into .emacs.

-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/20100424/a31113da/attachment-0001.pgp>


Ideas for making notmuch-hello easier to navigate

2010-04-24 Thread Carl Worth
On Fri, 23 Apr 2010 13:13:01 -0700, Carl Worth  wrote:
> That's the feedback I have from a very quick, first look. I'm sure I'll
> have more later.

In order to give notmuch-hello some good testing, I switched over to
using it exclusively instead of notmuch-folder. The biggest frustration
I'm having is easily picking the desired saved search with only the
keyboard, (I tend to be the kind of person that prefers the keyboard
over any mouse/trackpad/pointer-stick-thingy).


Re: [PATCH] emacs: Re-arrange message sending code

2010-04-24 Thread David Edmondson
On Fri, 23 Apr 2010 13:25:22 -0700, Carl Worth cwo...@cworth.org wrote:
 And I'm hoping that this new support makes it easier for people to hook
 in the Fcc code. Does this mean there's now a single place to add that
 that will make it work for messages composed from 'm', 'f', or 'r'?

Yes.

 The one unpleasantry I've noticed is that in the case of 'm' the headers
 are being put into the buffer in the following order:
 
   User-Agent:
   To:
   Subject:
   From:
 
 where I would prefer them in the following order:
 
   From:
   To:
   Subject:
   User-Agent:

I have:

(setq message-hidden-headers
  '(^References: ^Face: ^X-Face: ^X-Draft-From: ^User-Agent:))

so the User-Agent is not even visible.

dme.
-- 
David Edmondson, http://dme.org
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH 1/3] remove stale unused from around argv and argc in notmuch_show_command.

2010-04-24 Thread david
From: David Bremner brem...@unb.ca

In fact argc and argv are used in this function.
---
 notmuch-show.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/notmuch-show.c b/notmuch-show.c
index 26449fa..6aa9072 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -403,7 +403,7 @@ show_messages (void *ctx, const show_format_t *format, 
notmuch_messages_t *messa
 }
 
 int
-notmuch_show_command (void *ctx, unused (int argc), unused (char *argv[]))
+notmuch_show_command (void *ctx, int argc, char *argv[])
 {
 notmuch_config_t *config;
 notmuch_database_t *notmuch;
-- 
1.7.0

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH 2/3] notmuch-output.[ch]: initial implementation of output selection argument handling.

2010-04-24 Thread david
From: David Bremner brem...@unb.ca

These two files provide a more or less object oriented approach to
parsing output selection arguments.  The use of a struct to track
which output pieces are selected is intended to hide the
implementation, which currently uses bitmasks.
---
 Makefile.local   |1 +
 notmuch-output.c |   95 ++
 notmuch-output.h |   49 
 3 files changed, 145 insertions(+), 0 deletions(-)
 create mode 100644 notmuch-output.c
 create mode 100644 notmuch-output.h

diff --git a/Makefile.local b/Makefile.local
index 5bb570b..eb78679 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -240,6 +240,7 @@ notmuch_client_srcs =   \
notmuch-count.c \
notmuch-dump.c  \
notmuch-new.c   \
+   notmuch-output.c\
notmuch-reply.c \
notmuch-restore.c   \
notmuch-search.c\
diff --git a/notmuch-output.c b/notmuch-output.c
new file mode 100644
index 000..a84bbe1
--- /dev/null
+++ b/notmuch-output.c
@@ -0,0 +1,95 @@
+/* notmuch-output.h --- encapsulate handling of output selection.
+ *
+ * Copyright 2010 © David Bremner
+ *
+ * This file is part of Notmuch.
+ *
+ * Notmuch 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, either version 3 of the License, or (at
+ * your option) any later version.
+ *
+ * Notmuch 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 Notmuch.  If not, see http:www.gnu.org/licenses/.
+ *
+ * Authors: David Bremner da...@tethera.net
+ */
+
+#include notmuch-client.h
+#include notmuch-output.h
+
+notmuch_output_options_t *
+output_init(void *ctx){
+notmuch_output_options_t *output_opts;
+
+output_opts = talloc (ctx, notmuch_output_options_t);
+output_opts-output_all=TRUE;
+output_opts-mask=0;
+return output_opts;
+}
+
+int
+output_parse_arg(notmuch_output_options_t *output_opts, const char *arg){
+
+char *opt;
+
+struct { const char *name; notmuch_output_t key; } parse_try[]={
+  {bcc, NOTMUCH_OUTPUT_BCC},
+  {body, NOTMUCH_OUTPUT_BODY},
+  {cc, NOTMUCH_OUTPUT_CC},
+  {date,NOTMUCH_OUTPUT_DATE},
+  {from,NOTMUCH_OUTPUT_FROM},
+  {message-id,NOTMUCH_OUTPUT_MESSAGE_ID},
+  {subject,NOTMUCH_OUTPUT_SUBJECT},
+  {to, NOTMUCH_OUTPUT_TO},
+};
+
+opt = strchr(arg, '=');
+if (!opt)
+   return 1;
+
+opt++;
+
+output_opts-output_all=FALSE;
+
+while(opt) {
+   unsigned int i;
+   notmuch_bool_t found = FALSE;
+   notmuch_output_t key = 0;
+
+   for (i = 0; iARRAY_SIZE(parse_try) ; i++){
+   if (strncmp(opt, parse_try[i].name,
+   strlen(parse_try[i].name)) == 0){
+   key = parse_try[i].key;
+   found = TRUE;
+   }
+   }
+
+   if (!found) {
+   fprintf (stderr, Unrecognized output selection: %s\n, opt);
+   return 1;
+   }
+
+   output_opts-mask |= (1key);
+
+   opt = strchr(opt, ',');
+   if (opt) opt++;
+}
+
+return 0;
+}
+
+notmuch_bool_t
+output_get_flag(notmuch_output_options_t *opts,
+   notmuch_output_t flag){
+
+if (opts-output_all)
+   return 1;
+
+return (opts-mask  (1flag));
+}
diff --git a/notmuch-output.h b/notmuch-output.h
new file mode 100644
index 000..1216499
--- /dev/null
+++ b/notmuch-output.h
@@ -0,0 +1,49 @@
+/* notmuch-output.h --- encapsulate handling of output selection.
+ *
+ * Copyright 2010 © David Bremner
+ *
+ * This file is part of Notmuch.
+ *
+ * Notmuch 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, either version 3 of the License, or (at
+ * your option) any later version.
+ *
+ * Notmuch 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 Notmuch.  If not, see http:www.gnu.org/licenses/.
+ *
+ * Authors: David Bremner da...@tethera.net
+ */
+
+#ifndef NOTMUCH_OUTPUT_H
+#define NOTMUCH_OUTPUT_H
+
+typedef struct notmuch_output_struct {
+notmuch_bool_t output_all;
+int mask;
+} notmuch_output_options_t;
+
+typedef enum notmuch_output_enum {
+NOTMUCH_OUTPUT_BCC,
+NOTMUCH_OUTPUT_BODY,
+NOTMUCH_OUTPUT_CC,
+NOTMUCH_OUTPUT_DATE,
+NOTMUCH_OUTPUT_FROM,
+   

Ideas for making notmuch-hello easier to navigate

2010-04-24 Thread Carl Worth
On Fri, 23 Apr 2010 13:13:01 -0700, Carl Worth cwo...@cworth.org wrote:
 That's the feedback I have from a very quick, first look. I'm sure I'll
 have more later.

In order to give notmuch-hello some good testing, I switched over to
using it exclusively instead of notmuch-folder. The biggest frustration
I'm having is easily picking the desired saved search with only the
keyboard, (I tend to be the kind of person that prefers the keyboard
over any mouse/trackpad/pointer-stick-thingy).

From the initial screen, (with point at the upper-left corner), it takes
several keypresses of TAB before I get to the first saved search. It
might be even more natural to just use C-n to get to the line of
interest, but then I end up in the first column where the saved search
isn't active for RET.

Here are a few different ideas to simplify things:

  * Provide a target column from the beginning so that C-n moves point
to an active location.

  * Consider a single-column layout for saved searches so that C-n is
sufficient for selecting one.

  * Consider moving the name of the saved search to before the count so
that the initial column is active. Otherwise considering making a
larger active target, (name and count, maybe more). With a
single-column layout the whole row could be active.

  * Consider moving saved searches to above the big search bar. This way
the become the primary thing to access, which is what I want at
least. Then recent searches could stay just below the search bar,
which also makes sense. And for a new user, the big search bar would
be at the top which gives a good introduction to the system.

  * Provide keypbindings for next (and previous) saved search which
would move point to the next or previous saved-search name in the
buffer.

  * Provide a keypress for easily typing a name of a saved search. I
think I'd like this to work like i-search, but would only match
saved-search names, and a single press of RET would both terminate
the isearch and activate the saved search.

Any/all of those would help for selecting a single group. Then the other
feature that I would find essential, (and that notmuch-folder had):

  * Make it so that when quitting from a search and returning to
notmuch-hello, that point is at the same position it was before, (so
that q followed by RET returns the the same search view). This
would make it so that selecting the next search of interest would be
much easier than now.

Just throwing those ideas out in case anyone wants to try implementing
some and experimenting. I'm busy enough merging code now that I don't
have time to write any of the above yet, but I hope to have time to
start coding again soon.

-Carl


pgplnzjhrHEUm.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [notmuch] auto-tagging replied messages

2010-04-24 Thread Carl Worth
On Thu, 22 Apr 2010 12:35:16 +0200, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 On 2010-03-05, Jesse Rosenthal wrote:
  One element of traditional clients that I've missed in notmuch is the
  ability to easily see which messages have been replied to. A look at the
  thread structure will often make that clear, but for both searching and
  syncing, an answered tag would be nice.
 
 This patch has been working great so far and is very useful. Can I
 persuade someone to take this into the notmuch code and have a defcustom
 as to which tag a reply should get (or disable if nil)?

I'd like to see the in as well.

Since we name the action of responding to a message reply in the
documentation already, my vote for a default tag to add would be
replied.

Supporting the removal of a tag as well is clever, but I wouldn't
suggest doing that by default (the patch doesn't anyway). And instead,
people could do things like searches for tag:reply-required and not
tag:replied.

So here's my vote for someone cleaning this up into a patch that could
be applied directly to notmuch rather than just being a snippet of code
to shove into .emacs.

-Carl




pgp3DDQZf0XXT.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] emacs: Allow headers to be shown by default in show mode

2010-04-24 Thread Carl Worth
On Fri, 23 Apr 2010 21:08:48 +0100, David Edmondson d...@dme.org wrote:
 I like the current behaviour, but changing the default would be fine.

Which parts of it do you like? Being able to toggle the header back and
forth? Or just that the hidden headers take up so little vertical space?

I think that I would personally like to have the To and Cc headers
visible always. But having From and Date visible as separate rows is
redundant with our current summary bar, (well, Date isn't precisely
redundant).

I think I'll accept the patch, change the default, then remove From from
the list of headers inserted.

-Carl


pgpjPZaOr5ja2.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] emacs: Allow headers to be shown by default in show mode

2010-04-24 Thread Carl Worth
On Sat, 24 Apr 2010 05:42:54 -0700, Carl Worth cwo...@cworth.org wrote:
 I think I'll accept the patch, change the default, then remove From from
 the list of headers inserted.

I've done this now.

I've also exported the list of headers to display as another nice
customizable option in M-x customize-group notmuch.

For myself, I removed Date from that list too. That gives me a very
compact display without hiding too much information.

I didn't do that by default because several people recently said they'd
prefer to see the actual date rather than the relative date that's in
the summary line. I suppose another possibility would be to remove the
Date header by default and provide an option to display the actual date
in the summary-line instead of the relative date.

Someone that wants that could do that to get one more line of message
content per message displayed.

-Carl


pgpK7KCiKWPf0.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: notmuch segfault

2010-04-24 Thread Carl Worth
On Fri, 23 Apr 2010 15:26:51 +0200, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 It happened again. Both times I had pressed G which calls offlineimap
 and which removed messages that the notmuch database still thought are there.

Thanks for the report, Sebastian.

I've just audited all calls to notmuch_message_get_header and tried to
handle NULL in all cases.

Of course, I haven't tested this thoroughly, but we'll hope that things
are better at least.

And perhaps someday someone will hook up some exhaustive
fault-injection-based testing to catch things like this.

-Carl


pgpKlA9oPp9JV.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [notmuch] auto-tagging replied messages

2010-04-24 Thread Jesse Rosenthal
On Sat, 24 Apr 2010 05:38:36 -0700, Carl Worth cwo...@cworth.org wrote:
 So here's my vote for someone cleaning this up into a patch that could
 be applied directly to notmuch rather than just being a snippet of code
 to shove into .emacs.

I'd love to put this into shape to become part of notmuch proper. 

My question, for this and other things I've worked on, is where code
that targets message-mode should go. In notmuch-mua.el? Or a new
notmuch-message-utils.el? Or just a catch-all notmuch-utils.el? Once I
know where it would make the most sense to group these, I'll submit a
patch.

 Supporting the removal of a tag as well is clever, but I wouldn't
 suggest doing that by default (the patch doesn't anyway). And instead,
 people could do things like searches for tag:reply-required and not
 tag:replied.

But just to clarify: you don't mind if removal is a customizable user
option, right?

Best,
Jesse
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] notmuch.pod: pod version of documentation, converted by rman, massaged by hand.

2010-04-24 Thread David Bremner
On Thu, 31 Dec 2009 13:39:29 -0400, da...@tethera.net wrote:
 
 The idea here is to be able to generate the online help and the man page from 
 one source.
 
 To generate a man page:

pod2man notmuch.pod  notmuch.1
 
 To generate help for a specific notmuch subcommand
 
podselect -section 'Commands/subcommand.*' notmuch.pod | pod2text -c
 

As I'm faced with writing docs for output selection, I'd like to revisit
this idea. I didn't get any feedback, positive or negative about the
idea of keeping the docs in pod.  I don't care much about the format,
but I think it would be nice to avoid maintaining two copies of the
documentation.

Should I rebase/rebuild this against the current docs, or not bother?

d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: Unhandled Xapian exception

2010-04-24 Thread Carl Worth
On Fri, 23 Apr 2010 13:21:56 +0200, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 I propose to try..catch this code block and rather than returning VOID
 it could return NOTMUCH_STATUS_SUCCESS or NOTMUCH_XAPIAN_EXCEPTION.
 Not sure how notmuch_database_find_message would notify the caller of
 such an exception situation though. The only possible failure value is
 NULL (which also means did not find such a message).

We haven't been doing fine-grained exception handling in the library so
far. Mostly because the assumption was that there was nothing we could
do---when I first wrote the code I assumed that Xapian exceptions would
be entirely exceptional.

So I just fixed the top-level entry point here to handle this exception
in our standard way, (print the message, then return NULL or
NOTMUCH_STATUS_XAPIAN_EXCEPTION).

While at this, I audited all notmuch_database calls to ensure they
follow this scheme. (I have not yet audited all libnotmuch entry
points.)

Meanwhile, we've recently discovered that there is a Xapian exception
that is not all that exceptional. Since database readers don't lock the
database, it's not hard to have one or more readers accessing the
database when a writer comes along and modifies the database. This
triggers the readers to subsequently fail with a DatabaseModified
exception.

I don't know how conceivable it would be to fix that at the Xapian
level. It might be quite nice if opening a database in read-only mode
gave access to a snapshot of the database as it exists at that time. But
that might be a feature that's entirely unreasonable to implement.

Otherwise, we might want to start supporting more clever handling of the
exception. For example, the high-level application might want to retry
an operation if it fails due to a DatabaseModified exception. To support
this, you would want your python bindings to have a layer that would
catch the C++ exception and re-throw a python exception.

And to support that, we would need a different scheme in the
library. Basically to just document that all calls might throw an
exception and then not catch and print anything. That would at least be
much simpler in the library. Then the top-level notmuch application
could just have a C++ wrapper for main() that would catch and print the
exception message.

What do you think?

-Carl


pgp0CF9M6Lomx.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] emacs: Fix i-search to open up invisible citations as necessary

2010-04-24 Thread Carl Worth
On Fri, 23 Apr 2010 18:39:33 +0100, David Edmondson d...@dme.org wrote:
 Add an `isearch-open-invisible' property to the overlays used to hide
 citations and signatures, together with an appropriate function to
 leave the invisible text visible should that be required.

This is a fantastic feature, David. Thanks! This is pushed.

I knew emacs could do this kind of thing, and I had even tried to
implement it once, but I hadn't succeeded for some reason.

Next, I wonder if we shouldn't do something similar for the search
view. It might be quite handy if all authors and all unique subjects for
a thread were made available for i-search in the buffer, but hidden by
default and expanded as needed like this. What do you think?

-Carl


pgp8R9mtCafKN.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] emacs: Add more functions to clean up text/plain parts

2010-04-24 Thread Carl Worth
On Thu, 22 Apr 2010 13:26:06 +0100, David Edmondson d...@dme.org wrote:
 This is a small variant on the previous version of the patch. The
 wrapping of long lines is not enabled by default - it's simply an
 option in the customise interface.

This is really close now. I especially like that the various wash
options are as simple as just checkboxes in the customize
interface. (That might not even be new in this case, but I at least
didn't find it before.)

And that again goes to my point. I don't think we should enable this
washing by default since it can appear as silent corruption to the user,
without any indication that it happened nor how to turn it off.

Notmuch has always done some modification of the message with things
like hiding long citations, etc. But those at least provide
self-documenting buttons on how to make them disappear.

Here's what I see in the customize buffer with the latest patch, along
with some review. Some of this review applies to documentation already
in notmuch---I'm just getting pickier as things appear in
customize because I think we need to hold our documentation there to a
higher standard. (Previously, one would practically have to dive into
the source to find the documentation, and that suggests the reader has
more experience and definitely means the user gsts a lot more context).

Here, I'm trying to review these options from the point of view of a new
user who just started using notmuch, wants to tweak a few things, and is
looking at the customize buffer to figure out what tweaks are possible.

Notmuch Show Hook: 
[X] notmuch-show-pretty-hook
[ ] notmuch-show-turn-off-word-wrap
INS
   State: STANDARD.
   A list of functions called after populating a More

What does pretty hook mean? What information would a user need to
determine whether to turn this on or off?

With turn off word wrap, we have on option to disable wrapping here,
and another option later to turn some wrapping on again. How is a user
expected to figure out which combination of options does what they want?

Notmuch Show Insert Text/Plain Hook: Hide Value
[ ] notmuch-wash-wrap-long-lines
Wrap text in the region whilst maintaining the correct prefix.
[X] notmuch-wash-tidy-citations
Clean up citations.
[X] notmuch-wash-compress-blanks
Compress successive blank lines into one blank line. Remove More
[X] notmuch-wash-markup-citations
Markup citations, and up to one signature in the buffer.

Tidy, Clean up, and Markup citations are all too vague. What do
each of these actually do?

Also, think about line breaks so that something like Remove more
doesn't appear there by default.

Thanks,

-Carl


pgp9VyhafG8xj.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] Clean up author display for some Last, First cases

2010-04-24 Thread Carl Worth
On Wed, 21 Apr 2010 22:04:39 -0700, Dirk Hohndel hohn...@infradead.org wrote:
 +/* clean up the uggly Lastname, Firstname format that some mail systems
 + * (most notably, Exchange) are creating to be Firstname Lastname 
 + * To make sure that we don't change other potential situations where a 
 + * comma is in the name, we check that we match one of these patterns
 + * Last, First first.l...@company.com
 + * Last, First MI first.mi.l...@company.com

This is an interesting idea. We could make it a little more flexible by
doing a regexp comparison of first.*last against the email address,
(perhaps people have email addresses like carl_wo...@example.com?)

 +char *cleanauthor,*testauthor;

I'd much rather see an underscore separating two words in a single
identifier, (so clean_author, test_author).

 + /* let's assemble what we think is the correct name */
 + lname = comma - author;
 + fname = strlen(author) - lname - 2;
 + strncpy(cleanauthor, comma + 2, fname);
 + *(cleanauthor+fname) = ' ';
 + strncpy(cleanauthor + fname + 1, author, lname);
 + *(cleanauthor+fname+1+lname) = '\0';

The comment above, (what we think is the correct name), didn't help me
understand what the code is doing. And the code is hard enough to follow
that I could really use some help. Something like:

/* Break at comma and reverse: Last, First etc. - First Last etc. */

Lots of little additions here and there so plenty of chance for an
off-by-one. Do we have a test case for this yet?

 + /* make a temporary copy and see if it matches the email */
 + testauthor = xstrdup(cleanauthor);

It would be preferable to use talloc functions consistently. (Existing
occurrences of xstrdup in the code base are for the sake of
talloc-unfriendly glib data structures like GHashTable.)

As is, testauthor is leaking.

-Carl


pgpmhhsdbp2An.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Wrapping up the 0.3 release

2010-04-24 Thread Carl Worth
I pushed hard to get most everything we wanted for 0.3 done yesterday,
(which was one week since 0.2). I think we're still within the tolerance
of my published about a week schedule, but I would like to wrap things
up soon.

Here are the features that I still have left in my queue at this point:

  * improve from-header guessing

Dirk is looking into fixing a segfault found by the test suite here

  * Fcc, Maildir, and Emacs message-mode -- a bit of code

This is next on my list to apply. Thanks for the extra testing!

There are a few other features that people had proposed but that didn't
pass review yet. If people follow-up with those quickly, they can still
go in. Otherwise, there's another new merge window coming up soon!

Meanwhile, I'm aware of two regressions I'd like to see fixed before
0.3:

  * Reply is now splitting the window

We're copying the original message into the new reply buffer, so
what's the advantage of splitting here?

  * Composing a new message with 'm' brings up headers in a scrambled
order.

A minor point, but it would be nice to fix this.

Finally, any of the tweaks I suggested to notmuch-hello mode would be
quite welcome. I might take a whack at some of these.

Then, there's the task of writing up NEWS. Dirk started helping with
that, which I appreciate. If anyone else wants to write up descriptions
of their favorite features that have been merged, that would be great.

-Carl





pgp9kQqOqzLl2.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] removed unused variables

2010-04-24 Thread Dirk Hohndel
On Fri, 23 Apr 2010 17:55:09 -0700, Carl Worth cwo...@cworth.org wrote:
 On Thu, 22 Apr 2010 20:26:46 -0700, Dirk Hohndel hohn...@infradead.org 
 wrote:
  
  trivial compiler warning fix
 
 Thanks. I finally caught up to this.
 
 I had seen this patch from you earlier, when I didn't have a convenient
 working-directory for just applying it---so I've been religiously
 ignoring those warnings ever since rather than just fixing them. ;-)

This is something that I got caught in last night. I have brought in
more patches from others, worked on my own patches, and suddenly I
got stuck in git-branch-hell and couldn't figure out how to move changes
from one branch to another. That's why my reply-guessing-segfault fix is
not relative to my last patch...

I'm trying to clean up my mess this morning :-)

/D
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: Wrapping up the 0.3 release

2010-04-24 Thread Dirk Hohndel

On Sat, 24 Apr 2010 08:37:11 -0700, Carl Worth cwo...@cworth.org wrote:
 I pushed hard to get most everything we wanted for 0.3 done yesterday,
 (which was one week since 0.2). I think we're still within the tolerance
 of my published about a week schedule, but I would like to wrap things
 up soon.
 
 Here are the features that I still have left in my queue at this point:
 
   * improve from-header guessing
 
 Dirk is looking into fixing a segfault found by the test suite here

I sent a patch last night - but it's not realtive to the last thing that
I sent, instead relative to last night's master. Do you want me to
create another one?

Basically, the way I was trying to do concatenation of Received headers
earlier was fundamentally broken - it made assumptions about being able
to continue reading the headers even after we closed the file already.

Not so good.
 
   * Fcc, Maildir, and Emacs message-mode -- a bit of code
 
 This is next on my list to apply. Thanks for the extra testing!
 
 There are a few other features that people had proposed but that didn't
 pass review yet. If people follow-up with those quickly, they can still
 go in. Otherwise, there's another new merge window coming up soon!

I'll be working on notmuch for the next few hours and once my git trees
are straightened out again, I'll look into what's missing from my wish
list

 Meanwhile, I'm aware of two regressions I'd like to see fixed before
 0.3:
 
   * Reply is now splitting the window
 
 We're copying the original message into the new reply buffer, so
 what's the advantage of splitting here?

I'll voice my don't like of this feature as well, I guess.

   * Composing a new message with 'm' brings up headers in a scrambled
 order.
 
 A minor point, but it would be nice to fix this.

It doesn't for me with origin/master. Or let me double check... what do
you think would be the correct order (as this is a matter of taste for
some people)...

 Finally, any of the tweaks I suggested to notmuch-hello mode would be
 quite welcome. I might take a whack at some of these.
 
 Then, there's the task of writing up NEWS. Dirk started helping with
 that, which I appreciate. If anyone else wants to write up descriptions
 of their favorite features that have been merged, that would be great.

I think we should make this a requirement for patches to include a
little NEWS blurb and either a test case or an explanation why there
isn't a test case...

/D
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] Clean up author display for some Last, First cases

2010-04-24 Thread Dirk Hohndel
On Sat, 24 Apr 2010 08:30:22 -0700, Carl Worth cwo...@cworth.org wrote:
 On Wed, 21 Apr 2010 22:04:39 -0700, Dirk Hohndel hohn...@infradead.org 
 wrote:
  +/* clean up the uggly Lastname, Firstname format that some mail systems
  + * (most notably, Exchange) are creating to be Firstname Lastname 
  + * To make sure that we don't change other potential situations where a 
  + * comma is in the name, we check that we match one of these patterns
  + * Last, First first.l...@company.com
  + * Last, First MI first.mi.l...@company.com
 
 This is an interesting idea. We could make it a little more flexible by
 doing a regexp comparison of first.*last against the email address,
 (perhaps people have email addresses like carl_wo...@example.com?)

I'll look into that. We actually had some discussion about this on IRC
and I was thinking of taking this feature to a new level... something
like: 
- by default we show names as they come in (least surprise)
- we offer to reverse Last, First
- we offer to shorten to FirstL
- we offer an alias map
So I could define that mail from cwo...@cworth.org gets the author
listed as cworth. Or as CarlW.

  +char *cleanauthor,*testauthor;
 
 I'd much rather see an underscore separating two words in a single
 identifier, (so clean_author, test_author).

Happy to comply to your preferences in the future

  +   /* let's assemble what we think is the correct name */
  +   lname = comma - author;
  +   fname = strlen(author) - lname - 2;
  +   strncpy(cleanauthor, comma + 2, fname);
  +   *(cleanauthor+fname) = ' ';
  +   strncpy(cleanauthor + fname + 1, author, lname);
  +   *(cleanauthor+fname+1+lname) = '\0';
 
 The comment above, (what we think is the correct name), didn't help me
 understand what the code is doing. And the code is hard enough to follow
 that I could really use some help. Something like:
 
 /* Break at comma and reverse: Last, First etc. - First Last etc. */

Ok, I'll try to be more explicit in documenting algorithms

 Lots of little additions here and there so plenty of chance for an
 off-by-one. Do we have a test case for this yet?

Nope. Will do.

  +   /* make a temporary copy and see if it matches the email */
  +   testauthor = xstrdup(cleanauthor);
 
 It would be preferable to use talloc functions consistently. (Existing
 occurrences of xstrdup in the code base are for the sake of
 talloc-unfriendly glib data structures like GHashTable.)
 
 As is, testauthor is leaking.

Oops.

/D
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] emacs: Fix i-search to open up invisible citations as necessary

2010-04-24 Thread Dirk Hohndel
On Sat, 24 Apr 2010 07:42:48 -0700, Carl Worth cwo...@cworth.org wrote:
 On Fri, 23 Apr 2010 18:39:33 +0100, David Edmondson d...@dme.org wrote:
  Add an `isearch-open-invisible' property to the overlays used to hide
  citations and signatures, together with an appropriate function to
  leave the invisible text visible should that be required.
 
 This is a fantastic feature, David. Thanks! This is pushed.
 
 I knew emacs could do this kind of thing, and I had even tried to
 implement it once, but I hadn't succeeded for some reason.
 
 Next, I wonder if we shouldn't do something similar for the search
 view. It might be quite handy if all authors and all unique subjects for
 a thread were made available for i-search in the buffer, but hidden by
 default and expanded as needed like this. What do you think?

I would love this

/D
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] Add NEWS updates for my last batch of patches

2010-04-24 Thread micah anderson
On Fri, 23 Apr 2010 10:42:31 -0700, Dirk Hohndel hohn...@infradead.org wrote:

 +Provide 'G' key binding to trigger mail refresh
 +
 +  The 'G' key works wherever '=' works. Before refreshing the screen
 +  it calls an external program that can be used to poll email servers,
 +  run notmuch new and setup specific tags for the new emails. The
 +  script to be called can be customized with. Use the customize screen

Strange sentence: The script to be called can be customized with. 

I'd suggest an improvement, but I'm not sure what it should read.

micah




pgpHRFND5fRMS.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] Reordering of thread authors to list matching authors first

2010-04-24 Thread Dirk Hohndel
On Fri, 23 Apr 2010 17:21:53 -0700, Carl Worth cwo...@cworth.org wrote:
 On Wed, 21 Apr 2010 20:58:27 -0700, Dirk Hohndel hohn...@infradead.org 
 wrote:
  When displaying threads as result of a search it makes sense to list those
  authors first who match the search. The matching authors are separated from 
  the
  non-matching ones with a '|' instead of a ','
 
 It seems a reasonable feature to me.

I switched back to origin/master to help get ready for 0.3 and
tremendously miss this feature :-) 
 
 Some notes on the patch:
 
  +void
  +notmuch_message_set_author (notmuch_message_t *message,
  +   const char *author)
  +{
  +message-author = talloc_strdup(message, author);
  +return;
  +}
 
 This is leaking any previously set author value, (admittedly, it's only
 a talloc leak so it will still get cleaned up when the message is
 cleaned up, but still.

Fixed in forthcoming revision of this patch

 
  +/* Set the author member of 'message' - this is the representation used
  + * when displaying the message
  + */
  +void
  +notmuch_message_set_author (notmuch_message_t *message, const char 
  *author);
  +
  +/* Get the author member of 'message'
  + */
  +const char *
  +notmuch_message_get_author (notmuch_message_t *message);
 
 The notmuch.h file is our publicly installed header file for the library
 interface. I don't think the feature here requires any new library
 interface. Even if it did, we wouldn't want a public function like
 set_author that could simply scramble internal state and change the
 result of future calls to get_author.

My mistake - moved them to notmuch-private.h

  +/*
  + * move authors of matched messages in the thread to 
  + * the front of the authors list, but keep them in
  + * existing order within their group
  + */
  +static void
  +_thread_move_matched_author (notmuch_thread_t *thread,
  +const char *author)
 
 The implementation here seems a bit fiddly.
 
 We already have two passes over the messages, (first all messages, and
 then all matched messages). And we're currently calling add_author from
 the first pass.
 
 How about simply calling a new add_matched_author from the second pass
 which would look very much like the existing add_author. Then we could
 change add_author to accumulate authors into an array rather than a
 string. Then, finally, we would append any of these authors not already
 in the matched_authors hash tabled onto the final string.
 
 That should be less code and easier to understand I think.
 
 I can take a whack at that later if you don't beat me to it.

Maybe I'm misunderstanding your proposed algorithm - but it seems quite
a bit more complicated than what I'm doing today...

/D
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


new patch series for author reordering code

2010-04-24 Thread Dirk Hohndel

I tried to break this out into logically independent pieces - but to connect
this as a series.  
First we add the authors member and accessors to message
Second the reordering of thread authors (still the original string based
algorithm that I used before - I couldn't quite make sense of cworth's proposed
algorithm
Third a NEWS blurb
Fourth test for the new functionality
Fifth a first simple routine to make author names easier to read - this one
undoes the typical Exchange ugliness

I think this could go into 0.3 as is. I've been using the mostly identical
previous version for about a week - the changes here are mostly cleanup based
on cworth's feedback.

I am planning to enhance the display author names in a friendlier way feature
in the future, capturing more cases.

/D

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH 2/5] Reorder displayed names of thread authors

2010-04-24 Thread Dirk Hohndel
When displaying threads as result of a search it makes sense to list those
authors first who match the search. The matching authors are separated from the
non-matching ones with a '|' instead of a ','

Imagine the default +inbox query. Those mails in the thread that
match the query are actually new (whatever that means). And some
people seem to think that it would be much better to see those author
names first. For example, imagine a long and drawn out thread that once
was started by me; you have long read the older part of the thread and
removed the inbox tag. Whenever a new email comes in on this thread,
prior to this patch the author column in the search display will first show
Dirk Hohndel - I think it should first show the actual author(s) of the new
mail(s).

Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
 lib/thread.cc |   77 +
 1 files changed, 77 insertions(+), 0 deletions(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index e1da060..c80bb26 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -32,6 +32,7 @@ struct _notmuch_thread {
 char *subject;
 GHashTable *authors_hash;
 char *authors;
+char *nonmatched_authors;
 GHashTable *tags;
 
 notmuch_message_list_t *message_list;
@@ -73,6 +74,79 @@ _thread_add_author (notmuch_thread_t *thread,
thread-authors = talloc_strdup (thread, author);
 }
 
+/*
+ * move authors of matched messages in the thread to
+ * the front of the authors list, but keep them in
+ * existing order within their group
+ */
+static void
+_thread_move_matched_author (notmuch_thread_t *thread,
+const char *author)
+{
+char *authors_copy;
+char *current_author;
+char *last_pipe,*next_pipe;
+int idx,nm_start,author_len,authors_len;
+
+if (thread-authors == NULL || author == NULL)
+   return;
+if (thread-nonmatched_authors == NULL)
+   thread-nonmatched_authors = thread-authors;
+author_len = strlen(author);
+authors_len = strlen(thread-authors);
+if (author_len == authors_len) {
+   /* just one author */
+   thread-nonmatched_authors += author_len;
+   return;
+}
+current_author = strcasestr(thread-authors, author);
+if (current_author == NULL)
+   return;
+/* how far inside the nonmatched authors is our author? */
+idx = current_author - thread-nonmatched_authors;
+if (idx  0) {
+   /* already among matched authors */
+   return;
+}
+/* are there any authors in the list after our author? */
+if (thread-nonmatched_authors + author_len  thread-authors + 
authors_len) {
+   /* we have to make changes, so let's get a temp copy */
+   authors_copy = talloc_strdup(thread,thread-authors);
+   /* nm_start is the offset into where the non-matched authors start */
+   nm_start = thread-nonmatched_authors - thread-authors;
+   /* copy this author and add the |  - the if clause above tells us 
there's more */
+   strncpy(thread-nonmatched_authors,author,author_len);
+   strncpy(thread-nonmatched_authors+author_len,| ,2);
+   thread-nonmatched_authors += author_len+2;
+   if (idx  0) {
+ /* we are actually moving authors around, not just changing the 
separator
+  * first copy the authors that came BEFORE our author */
+ strncpy(thread-nonmatched_authors, authors_copy+nm_start, idx-2);
+ /* finally, if there are authors AFTER our author, copy those */
+ if(author_len+nm_start+idx  authors_len) {
+   strncpy(thread-nonmatched_authors + idx - 2,, ,2);
+   strncpy(thread-nonmatched_authors + idx, authors_copy+nm_start + 
idx + author_len + 2,
+   authors_len - (nm_start + idx + author_len + 2));
+ }
+   }
+   /* finally let's make sure there's just one '|' in the authors string */
+   last_pipe = strchr(thread-authors,'|');
+   while (last_pipe) {
+   next_pipe = strchr(last_pipe+1,'|');
+   if (next_pipe)
+   *last_pipe = ',';
+   last_pipe = next_pipe;
+   }
+} else {
+   thread-nonmatched_authors += author_len;
+   /* so now all authors are matched - let's remove the '|' */
+   last_pipe = strchr(thread-authors,'|');
+   if (last_pipe)
+   *last_pipe = ',';
+}
+return;
+}
+
 /* Add 'message' as a message that belongs to 'thread'.
  *
  * The 'thread' will talloc_steal the 'message' and hold onto a
@@ -110,6 +184,7 @@ _thread_add_message (notmuch_thread_t *thread,
author = internet_address_mailbox_get_addr (mailbox);
}
_thread_add_author (thread, author);
+   notmuch_message_set_author (message, author);
}
g_object_unref (G_OBJECT (list));
 }
@@ -182,6 +257,7 @@ _thread_add_matched_message (notmuch_thread_t *thread,
notmuch_message_set_flag (hashed_message,
  

[PATCH 1/5] Add authors member to message

2010-04-24 Thread Dirk Hohndel
message-authors contains the author's name (as we want to print it)
get / set methods are declared in notmuch-private.h

Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
 lib/message.cc|   18 ++
 lib/notmuch-private.h |   10 ++
 2 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/lib/message.cc b/lib/message.cc
index 721c9a6..4b2f98f 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -35,6 +35,7 @@ struct _notmuch_message {
 char *thread_id;
 char *in_reply_to;
 char *filename;
+char *author;
 notmuch_message_file_t *message_file;
 notmuch_message_list_t *replies;
 unsigned long flags;
@@ -110,6 +111,7 @@ _notmuch_message_create (const void *talloc_owner,
 message-in_reply_to = NULL;
 message-filename = NULL;
 message-message_file = NULL;
+message-author = NULL;
 
 message-replies = _notmuch_message_list_create (message);
 if (unlikely (message-replies == NULL)) {
@@ -533,6 +535,22 @@ notmuch_message_get_tags (notmuch_message_t *message)
 return _notmuch_convert_tags(message, i, end);
 }
 
+const char *
+notmuch_message_get_author (notmuch_message_t *message)
+{
+return message-author;
+}
+
+void
+notmuch_message_set_author (notmuch_message_t *message,
+   const char *author)
+{
+if (message-author)
+   talloc_free(message-author);
+message-author = talloc_strdup(message, author);
+return;
+}
+
 void
 _notmuch_message_set_date (notmuch_message_t *message,
   const char *date)
diff --git a/lib/notmuch-private.h b/lib/notmuch-private.h
index 94cce1b..6e83cc3 100644
--- a/lib/notmuch-private.h
+++ b/lib/notmuch-private.h
@@ -275,6 +275,16 @@ _notmuch_message_talloc_copy_data (notmuch_message_t 
*message);
 void
 _notmuch_message_clear_data (notmuch_message_t *message);
 
+/* Set the author member of 'message' - this is the representation used
+ * when displaying the message */
+void
+notmuch_message_set_author (notmuch_message_t *message, const char *author);
+
+/* Get the author member of 'message' */
+const char *
+notmuch_message_get_author (notmuch_message_t *message);
+
+
 /* index.cc */
 
 notmuch_status_t
-- 
1.6.6.1

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH 3/5] Add NEWS section for author reordering

2010-04-24 Thread Dirk Hohndel
This should be required in all patches

Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
 NEWS |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/NEWS b/NEWS
index eba0fd5..c2057c2 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,13 @@
+
+Visualization of author names that match a search
+
+  When notmuch displays threads as the result of a search, it now
+  lists the authors that match the search before listing the other
+  authors in the thread. It inserts a pipe '|' symbol between the last
+  matching and first non-matching author. This is especially useful in
+  a search that includes tag:unread. Now the authors of the unread
+  messages in the thread are listed first.
+
 Notmuch 0.2 (2010-04-16)
 
 This is the second release of the notmuch mail system, with actual
-- 
1.6.6.1

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: Wrapping up the 0.3 release

2010-04-24 Thread David Edmondson
On Sat, 24 Apr 2010 09:53:17 -0700, Dirk Hohndel hohn...@infradead.org wrote:
* Reply is now splitting the window
  
  We're copying the original message into the new reply buffer, so
  what's the advantage of splitting here?
 
 I'll voice my don't like of this feature as well, I guess.

This depends at least somewhat on the setting of `pop-up-windows'. Maybe
we should:

 (let ((pop-up-windows nil))
  ...)

in the reply code?

I think that notmuch window handling generally needs some consideration
and improvement.

  Finally, any of the tweaks I suggested to notmuch-hello mode would be
  quite welcome. I might take a whack at some of these.

Hopefully early next week for me.

dme.
-- 
David Edmondson, http://dme.org
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: improve from-header guessing

2010-04-24 Thread Dirk Hohndel
On Fri, 23 Apr 2010 11:47:04 -0700, Carl Worth cwo...@cworth.org wrote:
 On Fri, 16 Apr 2010 13:51:40 -0700, Dirk Hohndel hohn...@infradead.org 
 wrote:
  The following two patches should address most of the concerns raised 
  to my previous series. 
 
 Allow me to raise new concerns then. ;-)

Any time
 
  The first patch simply adds an interface to obtain a concatenation of
  all instances of a specific header from an email.
 
 I was hoping to see the special-case value of NULL go away with this
 change.
 
 And I like that there's a new function to get the concatenated header,
 (I would prefer an unabbreviated name of get_concatenated_header than
 get_header_concat), but I don't like seeing all the existing callers of
 get_header updated to pass an extra 0. Instead, I'd prefer to see those
 calls unchanged, and a tiny new get_header that passes the 0 and then
 make the actual implementing function be static and named something like
 notmuch_message_file_get_header_internal.

Turns out that the way I did this was broken anyway. So we can simply
forget these patches and your concerns. I'm sure you'll raise new
concerns on the new (rearchitected) patches.

 Both patches have some trailing whitespace. I see these easily wince I
 have the following in my ~/.gitconfig:
 
   [core]
   whitespace = trailing-space,space-before-tab

I know. I'm trying to be better about checking whitespace pollution
before submitting things.

 Finally, I'd like to see some tests for this feature. (But we do have
 the feature already without tests, so I won't strictly block on that).

Hu? You even commited these already. Or am I reading email out of order
again? 

/D
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [notmuch] auto-tagging replied messages

2010-04-24 Thread Carl Worth

-- 
carl.d.wo...@intel.com
On Sat, 24 Apr 2010 09:56:04 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote:
 I'd love to put this into shape to become part of notmuch proper. 

Great!

 My question, for this and other things I've worked on, is where code
 that targets message-mode should go. In notmuch-mua.el? Or a new
 notmuch-message-utils.el? Or just a catch-all notmuch-utils.el? Once I
 know where it would make the most sense to group these, I'll submit a
 patch.

You can call it notmuch-message.el if you'd like.

I'm never a fan of something generic like -utils. Things like that seem
to grow without bounds.

 But just to clarify: you don't mind if removal is a customizable user
 option, right?

I don't mind at all. I was just happy to realize that we wouldn't have
to do any tag removal to make the feature useful out-of-the-box.

-Carl


pgpT9hGwmHKYk.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: Wrapping up the 0.3 release

2010-04-24 Thread Carl Worth
On Sat, 24 Apr 2010 09:53:17 -0700, Dirk Hohndel hohn...@infradead.org wrote:
 On Sat, 24 Apr 2010 08:37:11 -0700, Carl Worth cwo...@cworth.org wrote:

 I sent a patch last night - but it's not realtive to the last thing that
 I sent, instead relative to last night's master. Do you want me to
 create another one?

No, what you sent last night is perfect. That will be easier for me.

 It doesn't for me with origin/master. Or let me double check... what do
 you think would be the correct order (as this is a matter of taste for
 some people)...

The order in the reply buffer is fine. But with m I get the User-Agent
first which looks a bit strange.

Dirk also mentioned in IRC that there's a regression with the signature
being mispositioned before the quoted text with a reply buffer. Now that
I've added a signature, I'm noticing this as well.

 I think we should make this a requirement for patches to include a
 little NEWS blurb and either a test case or an explanation why there
 isn't a test case...

I've asked for these, but I haven't been pushing hard on this.

Review for some of these simple things would be much appreciated from
anybody on the list, (and would help ensure that patches are more likely
to be ready-to-go once I get them). So let's see more of things like
this from anyone on the list:

Looks like a great feature---now it just needs a test case.

I've tested this and it does just what I want. Here's a
follow-on patch that adds an item to the NEWS file for this.

I can't common on the specific logic of the patch, but I did
notice some trailing whitespace. You'll want to clean that up
and resubmit so the patch won't be rejected.

Thanks,

-Carl

-- 
carl.d.wo...@intel.com


pgpb7ymAi5uPb.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: Wrapping up the 0.3 release

2010-04-24 Thread Dirk Hohndel
On Sat, 24 Apr 2010 14:45:45 -0700, Carl Worth cwo...@cworth.org wrote:
  It doesn't for me with origin/master. Or let me double check... what do
  you think would be the correct order (as this is a matter of taste for
  some people)...
 
 The order in the reply buffer is fine. But with m I get the User-Agent
 first which looks a bit strange.

Yep, same here.
 
 Dirk also mentioned in IRC that there's a regression with the signature
 being mispositioned before the quoted text with a reply buffer. Now that
 I've added a signature, I'm noticing this as well.

Well - we don't seem to be adding the signature ourselves anymore... I
still don't quite understand where and how we hand over to the existing
message-mode functions - I why those decide to insert a signature at
point.

Here's a trivial patch that ALSO adds a signature at the end of the
message buffer (where it belongs). But I haven't figured out how to get
rid of the one above the reply...

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index acb7dbf..493cd0e 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -63,6 +63,7 @@
 ;; line and then the body.
 (with-temp-buffer
   (call-process notmuch-command nil t nil reply query-string)
+  (message-insert-signature)
   (goto-char (point-min))
   (if (re-search-forward ^$ nil t)
  (save-excursion

  I think we should make this a requirement for patches to include a
  little NEWS blurb and either a test case or an explanation why there
  isn't a test case...
 
 I've asked for these, but I haven't been pushing hard on this.

I will start playing the nagger
 
 Review for some of these simple things would be much appreciated from
 anybody on the list, (and would help ensure that patches are more likely
 to be ready-to-go once I get them). So let's see more of things like
 this from anyone on the list:
 
   Looks like a great feature---now it just needs a test case.
 
   I've tested this and it does just what I want. Here's a
   follow-on patch that adds an item to the NEWS file for this.
 
   I can't common on the specific logic of the patch, but I did
   notice some trailing whitespace. You'll want to clean that up
   and resubmit so the patch won't be rejected.

I can do all of those.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: Wrapping up the 0.3 release

2010-04-24 Thread Dirk Hohndel
On Sat, 24 Apr 2010 15:05:55 -0700, Dirk Hohndel hohn...@infradead.org wrote:
  Dirk also mentioned in IRC that there's a regression with the signature
  being mispositioned before the quoted text with a reply buffer. Now that
  I've added a signature, I'm noticing this as well.
 
 Well - we don't seem to be adding the signature ourselves anymore... I
 still don't quite understand where and how we hand over to the existing
 message-mode functions - I why those decide to insert a signature at
 point.

Learning elisp every day. I think I now understand at least somewhat
what's happening there...
 
 Here's a trivial patch that ALSO adds a signature at the end of the
 message buffer (where it belongs). But I haven't figured out how to get
 rid of the one above the reply...
 
 diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
 index acb7dbf..493cd0e 100644
 --- a/emacs/notmuch-mua.el
 +++ b/emacs/notmuch-mua.el
 @@ -63,6 +63,7 @@
  ;; line and then the body.
  (with-temp-buffer
(call-process notmuch-command nil t nil reply query-string)
 +  (message-insert-signature)
(goto-char (point-min))
(if (re-search-forward ^$ nil t)
 (save-excursion

This patch is of course completely bogus. But understanding why it was
bogus helped me come up with this patch, that hopefully makes more
sense. People who ACTUALLY understand elisp - please take a look

(I could have sworn there was a variable somewhere that gives me the
correct regex to search for a signature separator... but I can't find
it. so please replace '-- ' with that if you know)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index acb7dbf..05c9603 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -82,7 +82,13 @@
 (message-hide-headers)
 (save-excursion
   (goto-char (point-max))
-  (insert body))
+  (if (re-search-backward --  nil t)
+ (progn 
+   (forward-line -1)
+   (insert body))
+   (progn
+ (goto-char (point-max))
+ (insert body
 (set-buffer-modified-p nil)))
 
 (defun notmuch-mua-forward-message ()


-- 
Dirk Hohndel
Intel Open Source Technology Center
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH 7/7] Integrate notmuch-fcc mechansim

2010-04-24 Thread Dirk Hohndel

On Fri, 23 Apr 2010 11:38:57 +0200, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 I have gone wild and added a defcustom notmuch-fcc-dirs.
 Depending on the value of that variable we will not do any
 maildir fcc at all (nil, the default), or it is of the format
 ((defaultsentbox)
  (full name em...@address . Work/sentbox)
  (full name2 ema...@address2 . Work2/sentbox))

I love this feature (unsurprising, as I was the one who requested it
repeatedly...).

One question from the elisp noop:

 +   (let ((subdir (cdr (assoc (message-fetch-field from) 
 notmuch-fcc-dirs

Why not make this 

(let ((subdir (cdr (assoc-string (message-fetch-field from) 
notmuch-fcc-dirs t

and have the association be case insensitive?

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] configure: add ignored options for compatibility.

2010-04-24 Thread Cédric Cabessa
gentoo's ebuild script expects 2 more options for configure:
  --host (same format as --build)
  --datadir
---
 configure |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index ec8c3fd..c522ad8 100755
--- a/configure
+++ b/configure
@@ -77,7 +77,9 @@ Additional options are accepted for compatibility with other
 configure-script calling conventions, but don't do anything yet:
 
--build=cpu-vendor-os Currently ignored
+   --host=cpu-vendor-os  Currently ignored
--infodir=DIR   Currently ignored
+   --datadir=DIR   Currently ignored
--localstatedir=DIR Currently ignored
--libexecdir=DIRCurrently ignored
--disable-maintainer-mode   Currently ignored
@@ -119,8 +121,26 @@ for option; do
build_option=${build_option#*-}
build_vendor=${build_option%%-*}
build_os=${build_option#*-}
+elif [ ${option%%=*} = '--host' ] ; then
+   host_option=${option#*=}
+   case ${host_option} in
+   *-*-*) ;;
+   *)
+   echo Unrecognized value for --host option: ${host_option}
+   echo Should be: cpu-vendor-os
+   echo See:
+   echo   $0 --help
+   echo 
+   exit 1
+   esac
+   host_cpu=${host_option%%-*}
+   host_option=${host_option#*-}
+   host_vendor=${host_option%%-*}
+   host_os=${host_option#*-}
 elif [ ${option%%=*} = '--infodir' ] ; then
true
+elif [ ${option%%=*} = '--datadir' ] ; then
+   true
 elif [ ${option%%=*} = '--localstatedir' ] ; then
true
 elif [ ${option%%=*} = '--libexecdir' ] ; then
-- 
1.7.0.4

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch