[notmuch] Bulk message tagging

[Arian Kuschki]

Hi
-Original Message-
From: Carl Worth 
Sent: 17 April 2010 17:43

So one could query with sysconf and break things up into multiple
commands as needed.

Doesn't xargs do exactly this?

[PATCH] configure: Add support for GMime 2.6

[Adrien Bustany]

Just sending the patch again for the 0.3 merge window...

Cheers

Adrien

On Thu, 15 Apr 2010 19:41:55 -0400, Adrien Bustany 
wrote:
> Notmuch compiles just fine with GMime 2.6, so accept it in the configure
> script.
> ---
>  configure |5 +
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/configure b/configure
> index eebe075..d4d462f 100755
> --- a/configure
> +++ b/configure
> @@ -188,6 +188,11 @@ if pkg-config --modversion gmime-2.4 > /dev/null
> 2>&1; then
>  have_gmime=1
>  gmime_cflags=$(pkg-config --cflags gmime-2.4)
>  gmime_ldflags=$(pkg-config --libs gmime-2.4)
> +elif pkg-config --modversion gmime-2.6 > /dev/null 2>&1; then
> +printf "Yes.\n"
> +have_gmime=1
> +gmime_cflags=$(pkg-config --cflags gmime-2.6)
> +gmime_ldflags=$(pkg-config --libs gmime-2.6)
>  else
>  printf "No.\n"
>  have_gmime=0

[PATCH v2] Name thread based on matching msgs instead of first msg.

[Jesse Rosenthal]

At the moment all threads are named based on the name of the first message
in the thread. However, this can cause problems if people either start
new threads by replying-all (as unfortunately, many out there do) or
change the subject of their mails to reflect a shift in a thread on a
list.

This patch names threads based on (a) matches for the query, and (b) the
search order. If the search order is oldest-first (as in the default
inbox) it chooses the oldest matching message as the subject. If the
search order is newest-first it chooses the newest one.

Reply prefixes ("Re: ", "Aw: ", "Sv: ", "Vs: ") are ignored
(case-insensitively) so a Re: won't change the subject.

Note that this adds a "sort" argument to _notmuch_thread_create and
_thread_add_matched_message, so that when constructing the thread we can
be aware of the sort order.

Signed-off-by: Jesse Rosenthal 
---
This patch is rebased against current master, and offered for inclusion
in 0.3.

This patch is necessary for me to keep track of my mail, based on the
emailing habits of my correspondents. If others much prefer the original
behavior, I would still request that this feature be a configurable
option, even if not the default.

 lib/notmuch-private.h |3 ++-
 lib/query.cc  |3 ++-
 lib/thread.cc |   32 
 3 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/lib/notmuch-private.h b/lib/notmuch-private.h
index d52d84d..94cce1b 100644
--- a/lib/notmuch-private.h
+++ b/lib/notmuch-private.h
@@ -205,7 +205,8 @@ notmuch_thread_t *
 _notmuch_thread_create (void *ctx,
notmuch_database_t *notmuch,
const char *thread_id,
-   const char *query_string);
+   const char *query_string,
+   notmuch_sort_t sort);

 /* message.cc */

diff --git a/lib/query.cc b/lib/query.cc
index 10f8dc8..3e20f59 100644
--- a/lib/query.cc
+++ b/lib/query.cc
@@ -299,7 +299,8 @@ notmuch_threads_get (notmuch_threads_t *threads)
 return _notmuch_thread_create (threads->query,
   threads->query->notmuch,
   threads->thread_id,
-  threads->query->query_string);
+  threads->query->query_string,
+  threads->query->sort);
 }

 void
diff --git a/lib/thread.cc b/lib/thread.cc
index 3aa9d48..5bf8354 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -129,7 +129,8 @@ _thread_add_message (notmuch_thread_t *thread,

 static void
 _thread_add_matched_message (notmuch_thread_t *thread,
-notmuch_message_t *message)
+notmuch_message_t *message,
+notmuch_sort_t sort)
 {
 time_t date;
 notmuch_message_t *hashed_message;
@@ -142,6 +143,28 @@ _thread_add_matched_message (notmuch_thread_t *thread,
 if (date > thread->newest || ! thread->matched_messages)
thread->newest = date;

+const char *subject;
+const char *cleaned_subject;
+
+subject = notmuch_message_get_header (message, "subject");
+
+if ((strncasecmp (subject, "Re: ", 4) == 0) ||
+   (strncasecmp (subject, "Aw: ", 4) == 0) ||
+   (strncasecmp (subject, "Vs: ", 4) == 0) ||
+   (strncasecmp (subject, "Sv: ", 4) == 0)) {
+
+   cleaned_subject = talloc_strndup (thread,
+ subject + 4,
+ strlen(subject) - 4);
+} else {
+   cleaned_subject = talloc_strdup (thread, subject);
+}
+
+if ((sort == NOTMUCH_SORT_OLDEST_FIRST && date <= thread->newest) ||
+   (sort != NOTMUCH_SORT_OLDEST_FIRST && date == thread->newest)) {
+   thread->subject = talloc_strdup (thread, cleaned_subject);
+}
+
 thread->matched_messages++;

 if (g_hash_table_lookup_extended (thread->message_hash,
@@ -209,7 +232,8 @@ notmuch_thread_t *
 _notmuch_thread_create (void *ctx,
notmuch_database_t *notmuch,
const char *thread_id,
-   const char *query_string)
+   const char *query_string,
+   notmuch_sort_t sort)
 {
 notmuch_thread_t *thread;
 const char *thread_id_query_string;
@@ -296,7 +320,7 @@ _notmuch_thread_create (void *ctx,
_thread_add_message (thread, message);

if (! matched_is_subset_of_thread)
-   _thread_add_matched_message (thread, message);
+   _thread_add_matched_message (thread, message, sort);

_notmuch_message_close (message);
 }
@@ -323,7 +347,7 @@ _notmuch_thread_create (void *ctx,
 notmuch_messages_move_to_next (messages))
{
message = notmuch_messages_get (messages);
-   _thread_add_matched_message (thread, message);
+   _thread_add_matched_message (thread, message, sort);

The archive operation should only archive open messages

[Dirk Hohndel]

On Sat, 17 Apr 2010 08:28:49 -0700, Carl Worth  wrote:
> On Thu, 15 Apr 2010 16:59:13 -0400, Jameson Rollins  finestructure.net> wrote:
> > I actually *really* don't like that the space bar does this.  In fact, I
> > build my own notmuch-show-advance function in a notmuch-hacks.el that I
> > load to expressly get around this.
> 
> Well we definitely do need that operation ("advance to next thread
> without archiving" to complement our existing "advance to next thread
> after archiving"). Any suggestions for what the keybinding should be for
> that? What are you using?

I have been going back and forth about which key to use... My current
favorite is 'k'eep. It kind of mirrors nicely with 'a'rchive.

> And once we have that, changing space bar to only operate within the
> current thread and not doing any advancing will definitely make it a lot
> less magic and less confusing.

Yes, please.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

[Announce] notmuch release 0.2 now available

[Alex Ghitza]

Hi,

I'm not sure whether replying to the announcement email is the
appropriate way to report building and testing results, but here goes.

notmuch-0.2 built fine, but one test failed during 'make test'.  I have
put the indicated directory up at

http://aghitza.org/files/test.16707

with a tarred version at

http://aghitza.org/files/test.16707.tar

The machine and distribution are

Linux artin 2.6.33-ARCH #1 SMP PREEMPT Sun Apr 4 10:27:30 CEST 2010 
x86_64 Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz GenuineIntel GNU/Linux

It would seem that I have libxapian-1.1, and gmime-2.4.15.


As an academic, when I see a test grade of 49/50, I think "pretty damn
good", so I'm using 0.2 anyway :).  So far it's great, I'll report if I
have any trouble.  

Thanks to everybody who contributed to 0.2!



Best,
Alex



-- 
Alex Ghitza -- http://aghitza.org/
Lecturer in Mathematics -- The University of Melbourne -- Australia

[notmuch] Bulk message tagging

[Carl Worth]

On Fri, 16 Apr 2010 07:47:45 -0400, Jesse Rosenthal  
wrote:
> I've never run into this error.

I usually run into this with things like "rm * */*" or so.

> Is there a specific length that triggers
> it? If so, we could chunk the tagging command. Or does the max length
> depend on the machine and system?

It is system dependent. Here are a couple of things I found:

The archive operation should only archive open messages

[Carl Worth]

On Thu, 15 Apr 2010 17:18:30 -0400, Jesse Rosenthal  
wrote:
> Which is all just to say that I think that archiving is just a special
> case of tagging/untagging, and that the issues raised here should be
> considered across the larger general case.

I do agree that archiving is just a special-case of
tagging/untagging. And fortunately, I think the implementation matches
that, so consistency will be natural here.

You're also making the claim that the tagging behavior should be
consistent between the search-results and thread-content views and that
makes a lot of sense.

Earlier in your message, you wrote:

> However, when I have a long thread, and only one message in the inbox,
> tagging the thread, of course, tags all the messages in it "to-reply."
> Now, the way to do it might be to just change my habits, and only tag
> while in show-mode, as opposed to search-mode. But this does seem to be
> in conflict with the way I intuitively want to handle my mail, and I
> imagine I'm not the only one.

It's funny, because for a while we did have the tag operation in the
search view affecting only the messages that actually matched the
search. The problem we ran into was that if you archived a message from
the search view and then wanted to undo that, the "+ inbox" operation
would not work, (since archiving the messages made them no longer match
the current search).

We "fixed" that by making the tag operations affect all messages in the
thread.

It occurs to me that the real bug here is that the tag operation is
re-executing the search, rather than simply acting on the set of
messages being displayed. And that's a bug we've recently discussed and
want to fix.

Once we fix that, I think we can go back to having tag operations only
affect matched messages in the search view, and I agree that this will
be extremely convenient.

-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/20100417/bd8d47b8/attachment.pgp>

The archive operation should only archive open messages

[Carl Worth]

On Thu, 15 Apr 2010 16:59:13 -0400, Jameson Rollins  wrote:
> I actually *really* don't like that the space bar does this.  In fact, I
> build my own notmuch-show-advance function in a notmuch-hacks.el that I
> load to expressly get around this.

Well we definitely do need that operation ("advance to next thread
without archiving" to complement our existing "advance to next thread
after archiving"). Any suggestions for what the keybinding should be for
that? What are you using?

And once we have that, changing space bar to only operate within the
current thread and not doing any advancing will definitely make it a lot
less magic and less confusing.

So I'm in favor of that at least.

>  The only tag manipulation I want
> done automatically is removal of "unread" when I visit a message.  Other
> than that, I want to do all tag manipulation manually.  So I would be
> thrilled is this "feature" was removed entirely, which would of course
> get rid of this bug as well.

The bug is still present for the explicit "archive this thread"
operation, (even if we disentangled it from any notion of advancing to
the next thread). So we'll still want to fix that.

> > [*] My tag:to-me is set by a script doing "notmuch tag +to-me
> > to:cworth at cworth.org or to:carl.d.worth at intel.com ...". I'd prefer 
> > this
> > to be a saved-search of course---that's one of the patches I haven't had
> > a chance to review yet.
> 
> I've asked this in the past, but isn't this exactly what notmuch
> "folders" are?  Is there a reason you don't just define this search as a
> folder?

I can define to-me as a folder (and I do do that). The reason I want
saved searches is that I also want to have folders such as "notmuch
to-me", "cairo to-me", etc. with common sub-expressions for what to-me
means. And if I add an email address I want to be able to update that in
1 place rather than in N different folder specification.

It's probably simpler to call these "search macros" rather than "saved
searches", because that's all the feature really is.

-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/20100417/7f6e2328/attachment.pgp>

Re: The archive operation should only archive open messages

[Carl Worth]

On Thu, 15 Apr 2010 16:59:13 -0400, Jameson Rollins 
jroll...@finestructure.net wrote:
 I actually *really* don't like that the space bar does this.  In fact, I
 build my own notmuch-show-advance function in a notmuch-hacks.el that I
 load to expressly get around this.

Well we definitely do need that operation (advance to next thread
without archiving to complement our existing advance to next thread
after archiving). Any suggestions for what the keybinding should be for
that? What are you using?

And once we have that, changing space bar to only operate within the
current thread and not doing any advancing will definitely make it a lot
less magic and less confusing.

So I'm in favor of that at least.

  The only tag manipulation I want
 done automatically is removal of unread when I visit a message.  Other
 than that, I want to do all tag manipulation manually.  So I would be
 thrilled is this feature was removed entirely, which would of course
 get rid of this bug as well.

The bug is still present for the explicit archive this thread
operation, (even if we disentangled it from any notion of advancing to
the next thread). So we'll still want to fix that.

  [*] My tag:to-me is set by a script doing notmuch tag +to-me
  to:cwo...@cworth.org or to:carl.d.wo...@intel.com  I'd prefer this
  to be a saved-search of course---that's one of the patches I haven't had
  a chance to review yet.
 
 I've asked this in the past, but isn't this exactly what notmuch
 folders are?  Is there a reason you don't just define this search as a
 folder?

I can define to-me as a folder (and I do do that). The reason I want
saved searches is that I also want to have folders such as notmuch
to-me, cairo to-me, etc. with common sub-expressions for what to-me
means. And if I add an email address I want to be able to update that in
1 place rather than in N different folder specification.

It's probably simpler to call these search macros rather than saved
searches, because that's all the feature really is.

-Carl


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

Re: The archive operation should only archive open messages

[Carl Worth]

On Thu, 15 Apr 2010 17:18:30 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote:
 Which is all just to say that I think that archiving is just a special
 case of tagging/untagging, and that the issues raised here should be
 considered across the larger general case.

I do agree that archiving is just a special-case of
tagging/untagging. And fortunately, I think the implementation matches
that, so consistency will be natural here.

You're also making the claim that the tagging behavior should be
consistent between the search-results and thread-content views and that
makes a lot of sense.

Earlier in your message, you wrote:

 However, when I have a long thread, and only one message in the inbox,
 tagging the thread, of course, tags all the messages in it to-reply.
 Now, the way to do it might be to just change my habits, and only tag
 while in show-mode, as opposed to search-mode. But this does seem to be
 in conflict with the way I intuitively want to handle my mail, and I
 imagine I'm not the only one.

It's funny, because for a while we did have the tag operation in the
search view affecting only the messages that actually matched the
search. The problem we ran into was that if you archived a message from
the search view and then wanted to undo that, the + inbox operation
would not work, (since archiving the messages made them no longer match
the current search).

We fixed that by making the tag operations affect all messages in the
thread.

It occurs to me that the real bug here is that the tag operation is
re-executing the search, rather than simply acting on the set of
messages being displayed. And that's a bug we've recently discussed and
want to fix.

Once we fix that, I think we can go back to having tag operations only
affect matched messages in the search view, and I agree that this will
be extremely convenient.

-Carl



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

[PATCH v2] Name thread based on matching msgs instead of first msg.

[Jesse Rosenthal]

At the moment all threads are named based on the name of the first message
in the thread. However, this can cause problems if people either start
new threads by replying-all (as unfortunately, many out there do) or
change the subject of their mails to reflect a shift in a thread on a
list.

This patch names threads based on (a) matches for the query, and (b) the
search order. If the search order is oldest-first (as in the default
inbox) it chooses the oldest matching message as the subject. If the
search order is newest-first it chooses the newest one.

Reply prefixes (Re: , Aw: , Sv: , Vs: ) are ignored
(case-insensitively) so a Re: won't change the subject.

Note that this adds a sort argument to _notmuch_thread_create and
_thread_add_matched_message, so that when constructing the thread we can
be aware of the sort order.

Signed-off-by: Jesse Rosenthal jrosent...@jhu.edu
---
This patch is rebased against current master, and offered for inclusion
in 0.3.

This patch is necessary for me to keep track of my mail, based on the
emailing habits of my correspondents. If others much prefer the original
behavior, I would still request that this feature be a configurable
option, even if not the default.

 lib/notmuch-private.h |3 ++-
 lib/query.cc  |3 ++-
 lib/thread.cc |   32 
 3 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/lib/notmuch-private.h b/lib/notmuch-private.h
index d52d84d..94cce1b 100644
--- a/lib/notmuch-private.h
+++ b/lib/notmuch-private.h
@@ -205,7 +205,8 @@ notmuch_thread_t *
 _notmuch_thread_create (void *ctx,
notmuch_database_t *notmuch,
const char *thread_id,
-   const char *query_string);
+   const char *query_string,
+   notmuch_sort_t sort);
 
 /* message.cc */
 
diff --git a/lib/query.cc b/lib/query.cc
index 10f8dc8..3e20f59 100644
--- a/lib/query.cc
+++ b/lib/query.cc
@@ -299,7 +299,8 @@ notmuch_threads_get (notmuch_threads_t *threads)
 return _notmuch_thread_create (threads-query,
   threads-query-notmuch,
   threads-thread_id,
-  threads-query-query_string);
+  threads-query-query_string,
+  threads-query-sort);
 }
 
 void
diff --git a/lib/thread.cc b/lib/thread.cc
index 3aa9d48..5bf8354 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -129,7 +129,8 @@ _thread_add_message (notmuch_thread_t *thread,
 
 static void
 _thread_add_matched_message (notmuch_thread_t *thread,
-notmuch_message_t *message)
+notmuch_message_t *message,
+notmuch_sort_t sort)
 {
 time_t date;
 notmuch_message_t *hashed_message;
@@ -142,6 +143,28 @@ _thread_add_matched_message (notmuch_thread_t *thread,
 if (date  thread-newest || ! thread-matched_messages)
thread-newest = date;
 
+const char *subject;
+const char *cleaned_subject;
+
+subject = notmuch_message_get_header (message, subject);
+
+if ((strncasecmp (subject, Re: , 4) == 0) ||
+   (strncasecmp (subject, Aw: , 4) == 0) ||
+   (strncasecmp (subject, Vs: , 4) == 0) ||
+   (strncasecmp (subject, Sv: , 4) == 0)) {
+
+   cleaned_subject = talloc_strndup (thread,
+ subject + 4,
+ strlen(subject) - 4);
+} else {
+   cleaned_subject = talloc_strdup (thread, subject);
+}
+
+if ((sort == NOTMUCH_SORT_OLDEST_FIRST  date = thread-newest) ||
+   (sort != NOTMUCH_SORT_OLDEST_FIRST  date == thread-newest)) {
+   thread-subject = talloc_strdup (thread, cleaned_subject);
+}
+
 thread-matched_messages++;
 
 if (g_hash_table_lookup_extended (thread-message_hash,
@@ -209,7 +232,8 @@ notmuch_thread_t *
 _notmuch_thread_create (void *ctx,
notmuch_database_t *notmuch,
const char *thread_id,
-   const char *query_string)
+   const char *query_string,
+   notmuch_sort_t sort)
 {
 notmuch_thread_t *thread;
 const char *thread_id_query_string;
@@ -296,7 +320,7 @@ _notmuch_thread_create (void *ctx,
_thread_add_message (thread, message);
 
if (! matched_is_subset_of_thread)
-   _thread_add_matched_message (thread, message);
+   _thread_add_matched_message (thread, message, sort);
 
_notmuch_message_close (message);
 }
@@ -323,7 +347,7 @@ _notmuch_thread_create (void *ctx,
 notmuch_messages_move_to_next (messages))
{
message = notmuch_messages_get (messages);
-   _thread_add_matched_message (thread, message);
+   _thread_add_matched_message (thread, message, sort);