Change duplicate priority?

[Jesse Rosenthal]

Dear All,

My work email comes through an Outlook server, which scans some
attachments. The process seems to be to first post an email with an
"Advanced Threat Protection" message and a link to a preview of the
attachment. Then, after the scan is complete, to delete that message and
post a second message, with the same Message ID, and the actual
attachment.

Depending on how long the scan takes, getmail might pull down both of
these emails. The second duplicate is available through the emacs change
index command, but the attachment is not available (since it tries to
pull the first attachment from the first version, which is just an html
part).

I can usually solve this by deleting the first one by hand, something
like:

notmuch search --output=files id: | head -1 | xargs rm

This has a couple of problems, though. (1) It's relying on the Maildir file
name being a time stamp to get rid of the earlier file, and (2) it
doesn't actually reindex the file when I run notmuch new, just treating
it as a rename, so I still get the search results for the older deleted
file.

I guess I could do a bindings-based script that gives me a bit more
confidence, dump the tags, delete the messages, reindex, and reapply the
tags.

But I wonder if there is some way to change the priority of duplicates
so that later versions overwrite earlier versions. Alternately, could
there be a way to specify which file name notmuch commands pull
attachments from? This would allow me to get the attachment that is only
on the second dup from the emacs interface.

The other (classical) approach, I guess, would be to put an mda in there
which only lets the second one through. But I'm trying to avoid
/dev/null-ing emails non-interactively if I possible can.

Thanks,
Jesse

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

[PATCH v3 2/2] lib: Use email address instead of empty real name.

[Jesse Rosenthal]

Currently, if a From-header is of the form:

"" 

the empty string will be treated as a valid real-name, and the entry
in the search results will be empty.

The new behavior here is that we treat an empty real-name field as if
it were null, so that the email address will be used in the search
results instead.

Signed-off-by: Jesse Rosenthal 
---
 lib/thread.cc  | 3 ++-
 test/T205-author-naming.sh | 1 -
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index 8922403..79c3e9b 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -277,7 +277,8 @@ _thread_add_message (notmuch_thread_t *thread,
address = internet_address_list_get_address (list, 0);
if (address) {
author = internet_address_get_name (address);
-   if (author == NULL) {
+   /* We treat quoted empty names as if they were empty. */
+   if (author == NULL || author[0] == '\0') {
InternetAddressMailbox *mailbox;
mailbox = INTERNET_ADDRESS_MAILBOX (address);
author = internet_address_mailbox_get_addr (mailbox);
diff --git a/test/T205-author-naming.sh b/test/T205-author-naming.sh
index 18819dd..cb678ae 100755
--- a/test/T205-author-naming.sh
+++ b/test/T205-author-naming.sh
@@ -3,7 +3,6 @@ test_description="naming of authors with unusual addresses"
 . ./test-lib.sh

 test_begin_subtest "Add author with empty quoted real name"
-test_subtest_known_broken
 add_message '[subject]="author-naming: Initial thread subject"' \
'[date]="Fri, 05 Jan 2001 15:43:56 -"' \
'[from]="\"\" "'
-- 
2.1.3

[PATCH v3 1/2] test: Add known-broken test for empty author name

[Jesse Rosenthal]

We test for whether a quoted empty email address

"" 

will show up as the address, instead of the empty string. This is
marked as known-broken, since the current behavior is to use the empty
string.

This is a new test file, since handling of unusual email addresses
doesn't seem to fit well in any of our existing tests.

Signed-off-by: Jesse Rosenthal 
---
 test/T205-author-naming.sh | 13 +
 1 file changed, 13 insertions(+)
 create mode 100755 test/T205-author-naming.sh

diff --git a/test/T205-author-naming.sh b/test/T205-author-naming.sh
new file mode 100755
index 000..18819dd
--- /dev/null
+++ b/test/T205-author-naming.sh
@@ -0,0 +1,13 @@
+#!/usr/bin/env bash
+test_description="naming of authors with unusual addresses"
+. ./test-lib.sh
+
+test_begin_subtest "Add author with empty quoted real name"
+test_subtest_known_broken
+add_message '[subject]="author-naming: Initial thread subject"' \
+   '[date]="Fri, 05 Jan 2001 15:43:56 -"' \
+   '[from]="\"\" "'
+output=$(notmuch search --sort=oldest-first author-naming and tag:inbox | 
notmuch_search_sanitize)
+test_expect_equal "$output" "thread:XXX   2001-01-05 [1/1] address at 
example.com; author-naming: Initial thread subject (inbox unread)"
+
+test_done
-- 
2.1.3

[PATCH v3 0/2] Use email address instead of empty real name.

[Jesse Rosenthal]

This version obsoletes [1].

The changes in this version are:

  * Commit test first with known-broken annotation, and then remove
that annotation in the second commit (when the test passes)

  * Style fixes in the thread.cc to conform with notmuch style.

[1] id:1416585462-24558-1-git-send-email-jrosenthal at jhu.edu

Jesse Rosenthal (2):
  test: Add known-broken test for empty author name
  lib: Use email address instead of empty real name.

 lib/thread.cc  |  3 ++-
 test/T205-author-naming.sh | 12 
 2 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100755 test/T205-author-naming.sh

-- 
2.1.3

[PATCH v3 1/2] test: Add known-broken test for empty author name

[Jesse Rosenthal]

We test for whether a quoted empty email address

 addr...@example.com

will show up as the address, instead of the empty string. This is
marked as known-broken, since the current behavior is to use the empty
string.

This is a new test file, since handling of unusual email addresses
doesn't seem to fit well in any of our existing tests.

Signed-off-by: Jesse Rosenthal jrosent...@jhu.edu
---
 test/T205-author-naming.sh | 13 +
 1 file changed, 13 insertions(+)
 create mode 100755 test/T205-author-naming.sh

diff --git a/test/T205-author-naming.sh b/test/T205-author-naming.sh
new file mode 100755
index 000..18819dd
--- /dev/null
+++ b/test/T205-author-naming.sh
@@ -0,0 +1,13 @@
+#!/usr/bin/env bash
+test_description=naming of authors with unusual addresses
+. ./test-lib.sh
+
+test_begin_subtest Add author with empty quoted real name
+test_subtest_known_broken
+add_message '[subject]=author-naming: Initial thread subject' \
+   '[date]=Fri, 05 Jan 2001 15:43:56 -' \
+   '[from]=\\ addr...@example.com'
+output=$(notmuch search --sort=oldest-first author-naming and tag:inbox | 
notmuch_search_sanitize)
+test_expect_equal $output thread:XXX   2001-01-05 [1/1] 
addr...@example.com; author-naming: Initial thread subject (inbox unread)
+
+test_done
-- 
2.1.3

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

[PATCH v3 0/2] Use email address instead of empty real name.

[Jesse Rosenthal]

This version obsoletes [1].

The changes in this version are:

  * Commit test first with known-broken annotation, and then remove
that annotation in the second commit (when the test passes)

  * Style fixes in the thread.cc to conform with notmuch style.

[1] id:1416585462-24558-1-git-send-email-jrosent...@jhu.edu

Jesse Rosenthal (2):
  test: Add known-broken test for empty author name
  lib: Use email address instead of empty real name.

 lib/thread.cc  |  3 ++-
 test/T205-author-naming.sh | 12 
 2 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100755 test/T205-author-naming.sh

-- 
2.1.3

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

[PATCH v3 2/2] lib: Use email address instead of empty real name.

[Jesse Rosenthal]

Currently, if a From-header is of the form:

 addr...@example.com

the empty string will be treated as a valid real-name, and the entry
in the search results will be empty.

The new behavior here is that we treat an empty real-name field as if
it were null, so that the email address will be used in the search
results instead.

Signed-off-by: Jesse Rosenthal jrosent...@jhu.edu
---
 lib/thread.cc  | 3 ++-
 test/T205-author-naming.sh | 1 -
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index 8922403..79c3e9b 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -277,7 +277,8 @@ _thread_add_message (notmuch_thread_t *thread,
address = internet_address_list_get_address (list, 0);
if (address) {
author = internet_address_get_name (address);
-   if (author == NULL) {
+   /* We treat quoted empty names as if they were empty. */
+   if (author == NULL || author[0] == '\0') {
InternetAddressMailbox *mailbox;
mailbox = INTERNET_ADDRESS_MAILBOX (address);
author = internet_address_mailbox_get_addr (mailbox);
diff --git a/test/T205-author-naming.sh b/test/T205-author-naming.sh
index 18819dd..cb678ae 100755
--- a/test/T205-author-naming.sh
+++ b/test/T205-author-naming.sh
@@ -3,7 +3,6 @@ test_description=naming of authors with unusual addresses
 . ./test-lib.sh
 
 test_begin_subtest Add author with empty quoted real name
-test_subtest_known_broken
 add_message '[subject]=author-naming: Initial thread subject' \
'[date]=Fri, 05 Jan 2001 15:43:56 -' \
'[from]=\\ addr...@example.com'
-- 
2.1.3

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

[PATCH v2 2/2] test: Add test for correct naming of author.

[Jesse Rosenthal]

This is a new test file, since handling of unusual email addresses
doesn't seem to fit well in any of our existing tests.

Signed-off-by: Jesse Rosenthal 
---
 test/T205-author-naming.sh | 12 
 1 file changed, 12 insertions(+)
 create mode 100755 test/T205-author-naming.sh

diff --git a/test/T205-author-naming.sh b/test/T205-author-naming.sh
new file mode 100755
index 000..cb678ae
--- /dev/null
+++ b/test/T205-author-naming.sh
@@ -0,0 +1,12 @@
+#!/usr/bin/env bash
+test_description="naming of authors with unusual addresses"
+. ./test-lib.sh
+
+test_begin_subtest "Add author with empty quoted real name"
+add_message '[subject]="author-naming: Initial thread subject"' \
+   '[date]="Fri, 05 Jan 2001 15:43:56 -"' \
+   '[from]="\"\" "'
+output=$(notmuch search --sort=oldest-first author-naming and tag:inbox | 
notmuch_search_sanitize)
+test_expect_equal "$output" "thread:XXX   2001-01-05 [1/1] address at 
example.com; author-naming: Initial thread subject (inbox unread)"
+
+test_done
-- 
2.1.3

[PATCH v2 1/2] lib: Use email address instead of empty real name.

[Jesse Rosenthal]

Currently, if a From-header is of the form:

"" 

the empty string will be treated as a valid real-name, and the entry
in the search results will be empty.

The new behavior here is that we treat an empty real-name field as if
it were null, so that the email address will be used in the search
results instead.

Signed-off-by: Jesse Rosenthal 
---
 lib/thread.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index 8922403..68b2b94 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -277,7 +277,8 @@ _thread_add_message (notmuch_thread_t *thread,
address = internet_address_list_get_address (list, 0);
if (address) {
author = internet_address_get_name (address);
-   if (author == NULL) {
+   // We treat quoted empty names as if they were empty.
+   if (author == NULL || author[0]=='\0' ) {
InternetAddressMailbox *mailbox;
mailbox = INTERNET_ADDRESS_MAILBOX (address);
author = internet_address_mailbox_get_addr (mailbox);
-- 
2.1.3

[PATCH v2 0/2] Use email address instead of empty real name.

[Jesse Rosenthal]

Apologies. A git (-user) malfunction in v1 accidentally sent the whole
mbox as one patch. These are the correct patches.

Jesse Rosenthal (2):
  lib: Use email address instead of empty real name.
  test: Add test for correct naming of author.

 lib/thread.cc  |  3 ++-
 test/T205-author-naming.sh | 12 
 2 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100755 test/T205-author-naming.sh

-- 
2.1.3

[PATCH 1/2] lib: Use email address instead of empty real name.

[Jesse Rosenthal]

Currently, if a From-header is of the form:

"" 

the empty string will be treated as a valid real-name, and the entry
in the search results will be empty.

The new behavior here is that we treat an empty real-name field as if
it were null, so that the email address will be used in the search
results instead.

Signed-off-by: Jesse Rosenthal 
---
 lib/thread.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index 8922403..68b2b94 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -277,7 +277,8 @@ _thread_add_message (notmuch_thread_t *thread,
address = internet_address_list_get_address (list, 0);
if (address) {
author = internet_address_get_name (address);
-   if (author == NULL) {
+   // We treat quoted empty names as if they were empty.
+   if (author == NULL || author[0]=='\0' ) {
InternetAddressMailbox *mailbox;
mailbox = INTERNET_ADDRESS_MAILBOX (address);
author = internet_address_mailbox_get_addr (mailbox);
-- 
2.1.3


>From 90fd4673e08fccef95dcc0050bdcac3773d336a9 Mon Sep 17 00:00:00 2001
From: Jesse Rosenthal <jrosent...@jhu.edu>
Date: Fri, 21 Nov 2014 10:24:16 -0500
Subject: [PATCH 2/2] test: Add test for correct naming of author.

This is a new test file, since handling of unusual email addresses
doesn't seem to fit well in any of our existing tests.

Signed-off-by: Jesse Rosenthal 
---
 test/T205-author-naming.sh | 12 
 1 file changed, 12 insertions(+)
 create mode 100755 test/T205-author-naming.sh

diff --git a/test/T205-author-naming.sh b/test/T205-author-naming.sh
new file mode 100755
index 000..cb678ae
--- /dev/null
+++ b/test/T205-author-naming.sh
@@ -0,0 +1,12 @@
+#!/usr/bin/env bash
+test_description="naming of authors with unusual addresses"
+. ./test-lib.sh
+
+test_begin_subtest "Add author with empty quoted real name"
+add_message '[subject]="author-naming: Initial thread subject"' \
+   '[date]="Fri, 05 Jan 2001 15:43:56 -"' \
+   '[from]="\"\" "'
+output=$(notmuch search --sort=oldest-first author-naming and tag:inbox | 
notmuch_search_sanitize)
+test_expect_equal "$output" "thread:XXX   2001-01-05 [1/1] address at 
example.com; author-naming: Initial thread subject (inbox unread)"
+
+test_done
-- 
2.1.3

[PATCH 1/2] lib: Use email address instead of empty real name.

[Jesse Rosenthal]

Currently, if a From-header is of the form:

 addr...@example.com

the empty string will be treated as a valid real-name, and the entry
in the search results will be empty.

The new behavior here is that we treat an empty real-name field as if
it were null, so that the email address will be used in the search
results instead.

Signed-off-by: Jesse Rosenthal jrosent...@jhu.edu
---
 lib/thread.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index 8922403..68b2b94 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -277,7 +277,8 @@ _thread_add_message (notmuch_thread_t *thread,
address = internet_address_list_get_address (list, 0);
if (address) {
author = internet_address_get_name (address);
-   if (author == NULL) {
+   // We treat quoted empty names as if they were empty.
+   if (author == NULL || author[0]=='\0' ) {
InternetAddressMailbox *mailbox;
mailbox = INTERNET_ADDRESS_MAILBOX (address);
author = internet_address_mailbox_get_addr (mailbox);
-- 
2.1.3


From 90fd4673e08fccef95dcc0050bdcac3773d336a9 Mon Sep 17 00:00:00 2001
From: Jesse Rosenthal jrosent...@jhu.edu
Date: Fri, 21 Nov 2014 10:24:16 -0500
Subject: [PATCH 2/2] test: Add test for correct naming of author.

This is a new test file, since handling of unusual email addresses
doesn't seem to fit well in any of our existing tests.

Signed-off-by: Jesse Rosenthal jrosent...@jhu.edu
---
 test/T205-author-naming.sh | 12 
 1 file changed, 12 insertions(+)
 create mode 100755 test/T205-author-naming.sh

diff --git a/test/T205-author-naming.sh b/test/T205-author-naming.sh
new file mode 100755
index 000..cb678ae
--- /dev/null
+++ b/test/T205-author-naming.sh
@@ -0,0 +1,12 @@
+#!/usr/bin/env bash
+test_description=naming of authors with unusual addresses
+. ./test-lib.sh
+
+test_begin_subtest Add author with empty quoted real name
+add_message '[subject]=author-naming: Initial thread subject' \
+   '[date]=Fri, 05 Jan 2001 15:43:56 -' \
+   '[from]=\\ addr...@example.com'
+output=$(notmuch search --sort=oldest-first author-naming and tag:inbox | 
notmuch_search_sanitize)
+test_expect_equal $output thread:XXX   2001-01-05 [1/1] 
addr...@example.com; author-naming: Initial thread subject (inbox unread)
+
+test_done
-- 
2.1.3

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

[PATCH v2 2/2] test: Add test for correct naming of author.

[Jesse Rosenthal]

This is a new test file, since handling of unusual email addresses
doesn't seem to fit well in any of our existing tests.

Signed-off-by: Jesse Rosenthal jrosent...@jhu.edu
---
 test/T205-author-naming.sh | 12 
 1 file changed, 12 insertions(+)
 create mode 100755 test/T205-author-naming.sh

diff --git a/test/T205-author-naming.sh b/test/T205-author-naming.sh
new file mode 100755
index 000..cb678ae
--- /dev/null
+++ b/test/T205-author-naming.sh
@@ -0,0 +1,12 @@
+#!/usr/bin/env bash
+test_description=naming of authors with unusual addresses
+. ./test-lib.sh
+
+test_begin_subtest Add author with empty quoted real name
+add_message '[subject]=author-naming: Initial thread subject' \
+   '[date]=Fri, 05 Jan 2001 15:43:56 -' \
+   '[from]=\\ addr...@example.com'
+output=$(notmuch search --sort=oldest-first author-naming and tag:inbox | 
notmuch_search_sanitize)
+test_expect_equal $output thread:XXX   2001-01-05 [1/1] 
addr...@example.com; author-naming: Initial thread subject (inbox unread)
+
+test_done
-- 
2.1.3

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

[PATCH v2 1/2] lib: Use email address instead of empty real name.

[Jesse Rosenthal]

Currently, if a From-header is of the form:

 addr...@example.com

the empty string will be treated as a valid real-name, and the entry
in the search results will be empty.

The new behavior here is that we treat an empty real-name field as if
it were null, so that the email address will be used in the search
results instead.

Signed-off-by: Jesse Rosenthal jrosent...@jhu.edu
---
 lib/thread.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index 8922403..68b2b94 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -277,7 +277,8 @@ _thread_add_message (notmuch_thread_t *thread,
address = internet_address_list_get_address (list, 0);
if (address) {
author = internet_address_get_name (address);
-   if (author == NULL) {
+   // We treat quoted empty names as if they were empty.
+   if (author == NULL || author[0]=='\0' ) {
InternetAddressMailbox *mailbox;
mailbox = INTERNET_ADDRESS_MAILBOX (address);
author = internet_address_mailbox_get_addr (mailbox);
-- 
2.1.3

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

[PATCH v2 0/2] Use email address instead of empty real name.

[Jesse Rosenthal]

Apologies. A git (-user) malfunction in v1 accidentally sent the whole
mbox as one patch. These are the correct patches.

Jesse Rosenthal (2):
  lib: Use email address instead of empty real name.
  test: Add test for correct naming of author.

 lib/thread.cc  |  3 ++-
 test/T205-author-naming.sh | 12 
 2 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100755 test/T205-author-naming.sh

-- 
2.1.3

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

[PATCH] test: Make gen-threads work with python3

[Jesse Rosenthal]

"W. Trevor King"  writes:

> On Fri, Oct 31, 2014 at 01:33:25PM -0400, Jesse Rosenthal wrote:
>> We instead initalize the dictionary using the dict comprehension and
>> then update it with the values from the tree. This will work with
>> both python2 and python3.
>
> Dict comprehensions are new in 2.7 [1,2], so this drops support for
> systems where ?python? means ?python2.6?.  Personally, I'm fine with
> that, but I thought I'd point it out in case 2.6 users wanted to push
> back ;).

The comprehension was already in the previous version, so I figured that
people were already cool with 2.7+.

>> -
>>  import sys
>
> Why remove this blank line?

Oops -- I had put in a print_function import from __future__ for
testing. Must have lost the line when I took it back out. Is it worth
resubmitting to fix that?

[PATCH] test: Make gen-threads work with python3

[Jesse Rosenthal]

python3 doesn't allow dictionaries to be initialized with non-string
keywords. This presents problems on systems in which "python" means
"python3". We instead initalize the dictionary using the dict
comprehension and then update it with the values from the tree. This
will work with both python2 and python3.
---
 test/gen-threads.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/test/gen-threads.py b/test/gen-threads.py
index 9fbb847..70fb1f6 100644
--- a/test/gen-threads.py
+++ b/test/gen-threads.py
@@ -2,7 +2,6 @@
 # argv[1].  Each output line is a thread structure, where the n'th
 # field is either a number giving the parent of message n or "None"
 # for the root.
-
 import sys
 from itertools import chain, combinations

@@ -28,6 +27,7 @@ while queue:
 else:
 # Expand node to_expand[0] with each possible set of children
 for children in subsets(free):
-ntree = dict(tree, **{child: to_expand[0] for child in children})
+ntree = {child: to_expand[0] for child in children}
+ntree.update(tree)
 nfree = free.difference(children)
 queue.append((ntree, nfree, to_expand[1:] + tuple(children)))
-- 
2.1.2

[PATCH v5 0/7] notmuch search --output=sender/recipients

[Jesse Rosenthal]

Dear Michal,

Thanks for all this. The feature looks great! One issue: I'm getting
corrupt output when using `--output=count` with "fold" filters:

~~~
jkr at ladybug [11:01AM] ~ $ notmuch search --output=recipients --output=count 
"tag:notmuch and date:today.." 
2   Jani Nikula 
2   Michal Sojka 
1   David Edmondson 
9   notmuch at notmuchmail.org

jkr at ladybug [11:01AM] ~ $ notmuch search --output=recipients --output=count 
--filter-by=addrfold "tag:notmuch and date:today.."
2   Michal Sojka <0Fam1 at fel.cvutH>
9   
1   David Edmondson <8dme.org>
2   Jani Nikula 

jkr at ladybug [11:01AM] ~ $ notmuch search --output=recipients --output=count 
--filter-by=nameaddr "tag:notmuch and date:today.."
2   Jani Nikula 
2   Michal Sojka 
1   David Edmondson 
9   notmuch at notmuchmail.org

jkr at ladybug [11:01AM] ~ $ notmuch search --output=recipients --output=count 
--filter-by=nameaddrfold "tag:notmuch and date:today.."
2   Jani Nikula 
2   Michal Sojka <0V?   am1 at fel.cvutH>
1   David Edmondson <8??dme.org>
9
~~~

Not sure if this is expected behavior with the filtering mechanism in
its current state, but I wanted to call it to your attention if not.

Best,
Jesse

Re: [PATCH v5 0/7] notmuch search --output=sender/recipients

[Jesse Rosenthal]

Dear Michal,

Thanks for all this. The feature looks great! One issue: I'm getting
corrupt output when using `--output=count` with fold filters:

~~~
jkr@ladybug [11:01AM] ~ $ notmuch search --output=recipients --output=count 
tag:notmuch and date:today.. 
2   Jani Nikula j...@nikula.org
2   Michal Sojka sojk...@fel.cvut.cz
1   David Edmondson d...@dme.org
9   notmuch@notmuchmail.org

jkr@ladybug [11:01AM] ~ $ notmuch search --output=recipients --output=count 
--filter-by=addrfold tag:notmuch and date:today..
2   Michal Sojka 0Fam1@fel.cvutH
9   
1   David Edmondson 8dme.org
2   Jani Nikula j...@nikula.org

jkr@ladybug [11:01AM] ~ $ notmuch search --output=recipients --output=count 
--filter-by=nameaddr tag:notmuch and date:today..
2   Jani Nikula j...@nikula.org
2   Michal Sojka sojk...@fel.cvut.cz
1   David Edmondson d...@dme.org
9   notmuch@notmuchmail.org

jkr@ladybug [11:01AM] ~ $ notmuch search --output=recipients --output=count 
--filter-by=nameaddrfold tag:notmuch and date:today..
2   Jani Nikula j...@nikula.org
2   Michal Sojka 0V�   am1@fel.cvutH
1   David Edmondson 8��dme.org
9
~~~

Not sure if this is expected behavior with the filtering mechanism in
its current state, but I wanted to call it to your attention if not.

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

[PATCH] test: Make gen-threads work with python3

[Jesse Rosenthal]

python3 doesn't allow dictionaries to be initialized with non-string
keywords. This presents problems on systems in which python means
python3. We instead initalize the dictionary using the dict
comprehension and then update it with the values from the tree. This
will work with both python2 and python3.
---
 test/gen-threads.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/test/gen-threads.py b/test/gen-threads.py
index 9fbb847..70fb1f6 100644
--- a/test/gen-threads.py
+++ b/test/gen-threads.py
@@ -2,7 +2,6 @@
 # argv[1].  Each output line is a thread structure, where the n'th
 # field is either a number giving the parent of message n or None
 # for the root.
-
 import sys
 from itertools import chain, combinations
 
@@ -28,6 +27,7 @@ while queue:
 else:
 # Expand node to_expand[0] with each possible set of children
 for children in subsets(free):
-ntree = dict(tree, **{child: to_expand[0] for child in children})
+ntree = {child: to_expand[0] for child in children}
+ntree.update(tree)
 nfree = free.difference(children)
 queue.append((ntree, nfree, to_expand[1:] + tuple(children)))
-- 
2.1.2

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

Re: [PATCH] test: Make gen-threads work with python3

[Jesse Rosenthal]

W. Trevor King wk...@tremily.us writes:

 On Fri, Oct 31, 2014 at 01:33:25PM -0400, Jesse Rosenthal wrote:
 We instead initalize the dictionary using the dict comprehension and
 then update it with the values from the tree. This will work with
 both python2 and python3.

 Dict comprehensions are new in 2.7 [1,2], so this drops support for
 systems where ‘python’ means ‘python2.6’.  Personally, I'm fine with
 that, but I thought I'd point it out in case 2.6 users wanted to push
 back ;).

The comprehension was already in the previous version, so I figured that
people were already cool with 2.7+.

 -
  import sys

 Why remove this blank line?

Oops -- I had put in a print_function import from __future__ for
testing. Must have lost the line when I took it back out. Is it worth
resubmitting to fix that?
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[v2 3/3] thread-naming test: Test empty subject names.

[Jesse Rosenthal]

We test all empty subjects, and then empty subjects followed by
non-empty subjects (searching both oldest- and newest-first).
---
 test/T200-thread-naming.sh | 32 
 1 file changed, 32 insertions(+)

diff --git a/test/T200-thread-naming.sh b/test/T200-thread-naming.sh
index 1a1a48f..dcfc1b3 100755
--- a/test/T200-thread-naming.sh
+++ b/test/T200-thread-naming.sh
@@ -63,6 +63,38 @@ add_message '[subject]="Sv: thread-naming: Initial thread 
subject"' \
 output=$(notmuch search --sort=newest-first thread-naming and tag:inbox | 
notmuch_search_sanitize)
 test_expect_equal "$output" "thread:XXX   2001-01-12 [6/8] Notmuch Test Suite; 
thread-naming: Initial thread subject (inbox unread)"

+test_begin_subtest "Use empty subjects if necessary."
+add_message '[subject]="@FORCE_EMPTY"' \
+   '[date]="Sat, 13 Jan 2001 15:43:45 -"' \
+'[from]="Empty Sender \"'
+empty_parent=${gen_msg_id}
+add_message '[subject]="@FORCE_EMPTY"' \
+   '[date]="Sun, 14 Jan 2001 15:43:45 -"' \
+'[from]="Empty Sender \"' \
+"[in-reply-to]=\<$empty_parent\>"
+output=$(notmuch search --sort=newest-first from:empty_test at notmuchmail.org 
| notmuch_search_sanitize)
+test_expect_equal "$output" "thread:XXX   2001-01-14 [2/2] Empty Sender;  
(inbox unread)"
+
+test_begin_subtest "Avoid empty subjects if possible (newest-first)."
+add_message '[subject]="Non-empty subject (1)"' \
+   '[date]="Mon, 15 Jan 2001 15:43:45 -"' \
+'[from]="Empty Sender \"' \
+"[in-reply-to]=\<$empty_parent\>"
+add_message '[subject]="Non-empty subject (2)"' \
+   '[date]="Mon, 16 Jan 2001 15:43:45 -"' \
+'[from]="Empty Sender \"' \
+"[in-reply-to]=\<$empty_parent\>"
+add_message '[subject]="@FORCE_EMPTY"' \
+   '[date]="Tue, 17 Jan 2001 15:43:45 -"' \
+'[from]="Empty Sender \"' \
+"[in-reply-to]=\<$empty_parent\>"
+output=$(notmuch search --sort=newest-first from:Empty | 
notmuch_search_sanitize)
+test_expect_equal "$output" "thread:XXX   2001-01-17 [5/5] Empty Sender; 
Non-empty subject (2) (inbox unread)"
+
+test_begin_subtest "Avoid empty subjects if possible (oldest-first)."
+output=$(notmuch search --sort=oldest-first from:Empty | 
notmuch_search_sanitize)
+test_expect_equal "$output" "thread:XXX   2001-01-13 [5/5] Empty Sender; 
Non-empty subject (1) (inbox unread)"
+
 test_begin_subtest 'Test order of messages in "notmuch show"'
 output=$(notmuch show thread-naming | notmuch_show_sanitize)
 test_expect_equal "$output" "message{ id:msg-$(printf "%03d" 
$first)@notmuch-test-suite depth:0 match:1 excluded:0 
filename:/XXX/mail/msg-$(printf "%03d" $first)
-- 
2.1.2

[v2 2/3] test-lib: Add dummy subject to force empty subject

[Jesse Rosenthal]

At the moment, the test-lib fills in any missing headers. This makes
it impossible to test our handling of empty subjects. This will
allow us to use a special dummy subject -- `@FORCE_EMPTY` -- to force
the subject to remain empty.
---
 test/test-lib.sh | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/test/test-lib.sh b/test/test-lib.sh
index 53db9ca..6057238 100644
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -368,6 +368,8 @@ generate_message ()
else
template[subject]="Test message #${gen_msg_cnt}"
fi
+elif [ "${template[subject]}" = "@FORCE_EMPTY" ]; then
+   template[subject]=""
 fi

 if [ -z "${template[date]}" ]; then
-- 
2.1.2

[v2 1/3] thread.cc: Avoid empty thread names if possible.

[Jesse Rosenthal]

Currently the thread is named based on either the oldest or newest
matching message (depending on the search order). If this message has
an empty subject, though, the thread will show up with an empty
subject in the search results. (See the thread starting with
`id:1412371140-21051-1-git-send-email-david at tethera.net` for an
example.)

This changes the behavior so it will use a non-empty name for the
thread if possible. We name threads based on (a) non-empty 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
non-empty message as the subject. If the search order is newest-first
it chooses the newest one.
---
 lib/thread.cc | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index 8922403..267f351 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -24,6 +24,8 @@
 #include 
 #include  /* GHashTable */

+#define EMPTY_STRING(s) ((s)[0] == '\0') 
+
 struct visible _notmuch_thread {
 notmuch_database_t *notmuch;
 char *thread_id;
@@ -330,11 +332,13 @@ _thread_set_subject_from_message (notmuch_thread_t 
*thread,
 } else {
cleaned_subject = talloc_strdup (thread, subject);
 }
+
+if (! EMPTY_STRING(cleaned_subject)) {
+   if (thread->subject)
+   talloc_free (thread->subject);

-if (thread->subject)
-   talloc_free (thread->subject);
-
-thread->subject = talloc_strdup (thread, cleaned_subject);
+   thread->subject = talloc_strdup (thread, cleaned_subject);
+}
 }

 /* Add a message to this thread which is known to match the original
@@ -348,8 +352,10 @@ _thread_add_matched_message (notmuch_thread_t *thread,
 {
 time_t date;
 notmuch_message_t *hashed_message;
+const char *cur_subject;

 date = notmuch_message_get_date (message);
+cur_subject = notmuch_thread_get_subject(thread);

 if (date < thread->oldest || ! thread->matched_messages) {
thread->oldest = date;
@@ -359,7 +365,7 @@ _thread_add_matched_message (notmuch_thread_t *thread,

 if (date > thread->newest || ! thread->matched_messages) {
thread->newest = date;
-   if (sort != NOTMUCH_SORT_OLDEST_FIRST)
+   if (sort != NOTMUCH_SORT_OLDEST_FIRST || EMPTY_STRING(cur_subject))
_thread_set_subject_from_message (thread, message);
 }

-- 
2.1.2

[v2 0/3] Avoid empty thread names if possible

[Jesse Rosenthal]

This is the second go at avoiding empty thread names. The differences
from the first version are:

  * Compare empty strings by checking for '\0' in first character
(using a macro) as suggested by Tomi Ollila.

  * Make sure that threads are titled correctly regardless of sorting
order. In this version we only add change the subject in
_thread_set_subject_from_message if the subject (after cleaning
"Re:") is non-empty. This is necessary for
oldest-first. newest-first works the same as before.

  * Add tests. This means that we have to force the test suite to
accept a non-empty header. I called the dummy subject
`@FORCE_EMPTY` to differentiate from a normal string, but not
invoke any special shell-ness. 

Jesse Rosenthal (3):
  thread.cc: Avoid empty thread names if possible.
  test-lib: Add dummy subject to force empty subject
  thread-naming test: Test empty subject names.

 lib/thread.cc  | 16 +++-
 test/T200-thread-naming.sh | 32 
 test/test-lib.sh   |  2 ++
 3 files changed, 45 insertions(+), 5 deletions(-)

-- 
2.1.2

[PATCH] Avoid empty thread names if possible.

[Jesse Rosenthal]

[I'm not sure why the below reply did not go to the list. Later replies
did, so I assume there must have been so problem in the sending. Mark,
apologies if you get this twice.]

Hi,

Thanks for taking a look at this.

Mark Walters  writes:
> I approve of the change in the output but I am unsure about the
> implementation. It would be nice to have a clear rule about which
> subject is taken. Eg: 
>
> if sort is oldest first then it is the subject of the oldest
> matching message with a non-empty subject. Similarly if sort
> is newest first.

The rule is actually in a four-year-old commit message (4971b85c4), in
almost exactly the same words you used:

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

So we would, essentially, just need to add "non-empty" to this
phrasing. Where would be the right place to put it? Commit message?
NEWS? `search` man page?

> Also, it would be nice if the implementation did not rely on what order
> we call _thread_add_matched_message on the matching messages in the
> thread. I think in some ways we already rely on the order (for the order
> of the author list), but if you want to rely on the order here I think
> it at least deserves a comment.

That would require a rethinking, I think, of naming -- since it's
traditionally worked in terms of renaming. When a better option comes,
we throw out the old one. So order is pretty essential. (Not saying
that's the best way, just pointing out that it's the way it's been done
since Carl's initial alpha release.)

> So looking at the above I think the oldest first gives the subject in
> my suggestion above (since the messages are supplied in oldest first
[ 4 more citation lines. Click/Enter to show. ]
> order). But newest first may not: indeed if the subject starts out as
> something and becomes empty then this will set the subject empty and
> then leave it

> (Note b_thread_set_subject_from_message calls notmuch_message_get_header
> which returns an empty string "" if the subject line is empty or not
> present).

Hmmm... I was looking at the following line in
_thread_set_subject_from_message:

subject = notmuch_message_get_header (message, "subject");
if (! subject)
return;

So, I don't think we ever actually change a content-ful string subject
to an empty one, as you describe above? If there's a non-empty string
there, and we get an empty subject, we leave the non-empty string in
place, right?

Best,
Jesse

[PATCH] Avoid empty thread names if possible.

[Jesse Rosenthal]

Hmm, that's strange -- my inital detailed response to Mark's message
didn't go through to the list. I wonder if it's being filtered or
something. 

[PATCH] Avoid empty thread names if possible.

[Jesse Rosenthal]

Thanks for taking a look.

Tomi Ollila  writes:

> IMO it is a bit silly to scan through the whole string and use the return
> value of 0 (vs != 0) to have effect. we should probably have something like
> #define EMPTY_STRING(s) ((s)[0] == '\0') 
> and use that instead.

Good point. Will put in the next version.

> Also, to keep promise, mentioning 'patch' in commit message referring to 
> the change introduced does IMO also look silly :D

Ah. Yep, agreed.

[PATCH] Avoid empty thread names if possible.

[Jesse Rosenthal]

By the way, this discussion brings up another problem. I wasn't able to
write a test for this (to address the below concerns) because the test
suite for thread-naming supplies some sort of auto-generated subject
for threads with empty subjects. So we can't test behavior for dealing
with empty subjects.

Unfortunately, I don't know the history of the test suite, or why this
auto-subject decisicion was made, so I don't feel comfortable just
changing the behavior.

[PATCH] Avoid empty thread names if possible.

[Jesse Rosenthal]

Hi,

Thanks for taking a look at this.

Mark Walters  writes:
> I approve of the change in the output but I am unsure about the
> implementation. It would be nice to have a clear rule about which
> subject is taken. Eg: 
>
> if sort is oldest first then it is the subject of the oldest
> matching message with a non-empty subject. Similarly if sort
> is newest first.

The rule is actually in a four-year-old commit message (4971b85c4), in
almost exactly the same words you used:

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

So we would, essentially, just need to add "non-empty" to this
phrasing. Where would be the right place to put it? Commit message?
NEWS? `search` man page?

> Also, it would be nice if the implementation did not rely on what order
> we call _thread_add_matched_message on the matching messages in the
> thread. I think in some ways we already rely on the order (for the order
> of the author list), but if you want to rely on the order here I think
> it at least deserves a comment.

That would require a rethinking, I think, of naming -- since it's
traditionally worked in terms of renaming. When a better option comes,
we throw out the old one. So order is pretty essential. (Not saying
that's the best way, just pointing out that it's the way it's been done
since Carl's initial alpha release.)

> So looking at the above I think the oldest first gives the subject in
> my suggestion above (since the messages are supplied in oldest first
> order). But newest first may not: indeed if the subject starts out as
> something and becomes empty then this will set the subject empty and
> then leave it

> (Note b_thread_set_subject_from_message calls notmuch_message_get_header
> which returns an empty string "" if the subject line is empty or not
> present).

Hmmm... I was looking at the following line in
_thread_set_subject_from_message:

subject = notmuch_message_get_header (message, "subject");
if (! subject)
return;

So, I don't think we ever actually change a content-ful string subject
to an empty one, as you describe above? If there's a non-empty string
there, and we get an empty subject, we leave the non-empty string in
place, right?

Best,
Jesse

Re: [PATCH] Avoid empty thread names if possible.

[Jesse Rosenthal]

By the way, this discussion brings up another problem. I wasn't able to
write a test for this (to address the below concerns) because the test
suite for thread-naming supplies some sort of auto-generated subject
for threads with empty subjects. So we can't test behavior for dealing
with empty subjects.

Unfortunately, I don't know the history of the test suite, or why this
auto-subject decisicion was made, so I don't feel comfortable just
changing the behavior.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] Avoid empty thread names if possible.

[Jesse Rosenthal]

Thanks for taking a look.

Tomi Ollila tomi.oll...@iki.fi writes:

 IMO it is a bit silly to scan through the whole string and use the return
 value of 0 (vs != 0) to have effect. we should probably have something like
 #define EMPTY_STRING(s) ((s)[0] == '\0') 
 and use that instead.

Good point. Will put in the next version.

 Also, to keep promise, mentioning 'patch' in commit message referring to 
 the change introduced does IMO also look silly :D

Ah. Yep, agreed.

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

Re: [PATCH] Avoid empty thread names if possible.

[Jesse Rosenthal]

[I'm not sure why the below reply did not go to the list. Later replies
did, so I assume there must have been so problem in the sending. Mark,
apologies if you get this twice.]

Hi,

Thanks for taking a look at this.

Mark Walters markwalters1...@gmail.com writes:
 I approve of the change in the output but I am unsure about the
 implementation. It would be nice to have a clear rule about which
 subject is taken. Eg: 

 if sort is oldest first then it is the subject of the oldest
 matching message with a non-empty subject. Similarly if sort
 is newest first.

The rule is actually in a four-year-old commit message (4971b85c4), in
almost exactly the same words you used:

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

So we would, essentially, just need to add non-empty to this
phrasing. Where would be the right place to put it? Commit message?
NEWS? `search` man page?

 Also, it would be nice if the implementation did not rely on what order
 we call _thread_add_matched_message on the matching messages in the
 thread. I think in some ways we already rely on the order (for the order
 of the author list), but if you want to rely on the order here I think
 it at least deserves a comment.

That would require a rethinking, I think, of naming -- since it's
traditionally worked in terms of renaming. When a better option comes,
we throw out the old one. So order is pretty essential. (Not saying
that's the best way, just pointing out that it's the way it's been done
since Carl's initial alpha release.)

 So looking at the above I think the oldest first gives the subject in
 my suggestion above (since the messages are supplied in oldest first
[ 4 more citation lines. Click/Enter to show. ]
 order). But newest first may not: indeed if the subject starts out as
 something and becomes empty then this will set the subject empty and
 then leave it

 (Note b_thread_set_subject_from_message calls notmuch_message_get_header
 which returns an empty string  if the subject line is empty or not
 present).

Hmmm... I was looking at the following line in
_thread_set_subject_from_message:

subject = notmuch_message_get_header (message, subject);
if (! subject)
return;

So, I don't think we ever actually change a content-ful string subject
to an empty one, as you describe above? If there's a non-empty string
there, and we get an empty subject, we leave the non-empty string in
place, right?

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

Re: [PATCH] Avoid empty thread names if possible.

[Jesse Rosenthal]

Hi,

Thanks for taking a look at this.

Mark Walters markwalters1...@gmail.com writes:
 I approve of the change in the output but I am unsure about the
 implementation. It would be nice to have a clear rule about which
 subject is taken. Eg: 

 if sort is oldest first then it is the subject of the oldest
 matching message with a non-empty subject. Similarly if sort
 is newest first.

The rule is actually in a four-year-old commit message (4971b85c4), in
almost exactly the same words you used:

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

So we would, essentially, just need to add non-empty to this
phrasing. Where would be the right place to put it? Commit message?
NEWS? `search` man page?

 Also, it would be nice if the implementation did not rely on what order
 we call _thread_add_matched_message on the matching messages in the
 thread. I think in some ways we already rely on the order (for the order
 of the author list), but if you want to rely on the order here I think
 it at least deserves a comment.

That would require a rethinking, I think, of naming -- since it's
traditionally worked in terms of renaming. When a better option comes,
we throw out the old one. So order is pretty essential. (Not saying
that's the best way, just pointing out that it's the way it's been done
since Carl's initial alpha release.)

 So looking at the above I think the oldest first gives the subject in
 my suggestion above (since the messages are supplied in oldest first
 order). But newest first may not: indeed if the subject starts out as
 something and becomes empty then this will set the subject empty and
 then leave it

 (Note b_thread_set_subject_from_message calls notmuch_message_get_header
 which returns an empty string  if the subject line is empty or not
 present).

Hmmm... I was looking at the following line in
_thread_set_subject_from_message:

subject = notmuch_message_get_header (message, subject);
if (! subject)
return;

So, I don't think we ever actually change a content-ful string subject
to an empty one, as you describe above? If there's a non-empty string
there, and we get an empty subject, we leave the non-empty string in
place, right?

Best,
Jesse

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

[v2 1/3] thread.cc: Avoid empty thread names if possible.

[Jesse Rosenthal]

Currently the thread is named based on either the oldest or newest
matching message (depending on the search order). If this message has
an empty subject, though, the thread will show up with an empty
subject in the search results. (See the thread starting with
`id:1412371140-21051-1-git-send-email-da...@tethera.net` for an
example.)

This changes the behavior so it will use a non-empty name for the
thread if possible. We name threads based on (a) non-empty 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
non-empty message as the subject. If the search order is newest-first
it chooses the newest one.
---
 lib/thread.cc | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index 8922403..267f351 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -24,6 +24,8 @@
 #include gmime/gmime.h
 #include glib.h /* GHashTable */
 
+#define EMPTY_STRING(s) ((s)[0] == '\0') 
+
 struct visible _notmuch_thread {
 notmuch_database_t *notmuch;
 char *thread_id;
@@ -330,11 +332,13 @@ _thread_set_subject_from_message (notmuch_thread_t 
*thread,
 } else {
cleaned_subject = talloc_strdup (thread, subject);
 }
+
+if (! EMPTY_STRING(cleaned_subject)) {
+   if (thread-subject)
+   talloc_free (thread-subject);
 
-if (thread-subject)
-   talloc_free (thread-subject);
-
-thread-subject = talloc_strdup (thread, cleaned_subject);
+   thread-subject = talloc_strdup (thread, cleaned_subject);
+}
 }
 
 /* Add a message to this thread which is known to match the original
@@ -348,8 +352,10 @@ _thread_add_matched_message (notmuch_thread_t *thread,
 {
 time_t date;
 notmuch_message_t *hashed_message;
+const char *cur_subject;
 
 date = notmuch_message_get_date (message);
+cur_subject = notmuch_thread_get_subject(thread);
 
 if (date  thread-oldest || ! thread-matched_messages) {
thread-oldest = date;
@@ -359,7 +365,7 @@ _thread_add_matched_message (notmuch_thread_t *thread,
 
 if (date  thread-newest || ! thread-matched_messages) {
thread-newest = date;
-   if (sort != NOTMUCH_SORT_OLDEST_FIRST)
+   if (sort != NOTMUCH_SORT_OLDEST_FIRST || EMPTY_STRING(cur_subject))
_thread_set_subject_from_message (thread, message);
 }
 
-- 
2.1.2

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

[v2 2/3] test-lib: Add dummy subject to force empty subject

[Jesse Rosenthal]

At the moment, the test-lib fills in any missing headers. This makes
it impossible to test our handling of empty subjects. This will
allow us to use a special dummy subject -- `@FORCE_EMPTY` -- to force
the subject to remain empty.
---
 test/test-lib.sh | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/test/test-lib.sh b/test/test-lib.sh
index 53db9ca..6057238 100644
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -368,6 +368,8 @@ generate_message ()
else
template[subject]=Test message #${gen_msg_cnt}
fi
+elif [ ${template[subject]} = @FORCE_EMPTY ]; then
+   template[subject]=
 fi
 
 if [ -z ${template[date]} ]; then
-- 
2.1.2

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

[v2 0/3] Avoid empty thread names if possible

[Jesse Rosenthal]

This is the second go at avoiding empty thread names. The differences
from the first version are:

  * Compare empty strings by checking for '\0' in first character
(using a macro) as suggested by Tomi Ollila.

  * Make sure that threads are titled correctly regardless of sorting
order. In this version we only add change the subject in
_thread_set_subject_from_message if the subject (after cleaning
Re:) is non-empty. This is necessary for
oldest-first. newest-first works the same as before.

  * Add tests. This means that we have to force the test suite to
accept a non-empty header. I called the dummy subject
`@FORCE_EMPTY` to differentiate from a normal string, but not
invoke any special shell-ness. 

Jesse Rosenthal (3):
  thread.cc: Avoid empty thread names if possible.
  test-lib: Add dummy subject to force empty subject
  thread-naming test: Test empty subject names.

 lib/thread.cc  | 16 +++-
 test/T200-thread-naming.sh | 32 
 test/test-lib.sh   |  2 ++
 3 files changed, 45 insertions(+), 5 deletions(-)

-- 
2.1.2

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

[PATCH] Avoid empty thread names if possible.

[Jesse Rosenthal]

Currently the thread is named based on either the oldest or newest
matching message (depending on the search order). If this message has
an empty subject, though, the thread will show up with an empty
subject in the search results. (See the thread starting with
`id:1412371140-21051-1-git-send-email-david at tethera.net` for an
example.)

This patch changes the behavior to name based on the oldest/newest
matching non-empty subject. This is particularly helpful for patchsets.
If the only subjects are empty, the thread subject will still be empty.

Signed-off-by: Jesse Rosenthal 
---
 lib/thread.cc | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index 8922403..ea10295 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -348,18 +348,20 @@ _thread_add_matched_message (notmuch_thread_t *thread,
 {
 time_t date;
 notmuch_message_t *hashed_message;
+const char *cur_subject;

 date = notmuch_message_get_date (message);
+cur_subject = notmuch_thread_get_subject (thread);

 if (date < thread->oldest || ! thread->matched_messages) {
thread->oldest = date;
-   if (sort == NOTMUCH_SORT_OLDEST_FIRST)
+   if (sort == NOTMUCH_SORT_OLDEST_FIRST || strlen(cur_subject) == 0)
_thread_set_subject_from_message (thread, message);
 }

 if (date > thread->newest || ! thread->matched_messages) {
thread->newest = date;
-   if (sort != NOTMUCH_SORT_OLDEST_FIRST)
+   if (sort != NOTMUCH_SORT_OLDEST_FIRST || strlen(cur_subject) == 0)
_thread_set_subject_from_message (thread, message);
 }

-- 
2.1.2

RFC: notmuch-cache.el: simple caching of MIME parts

[Jesse Rosenthal]

Hi David,

David Edmondson  writes:

> ...here is a very simple filesystem based cache of MIME parts for
> notmuch. It's integrated using defadvice for now, but a cleaner
> approach is obviously possible.

Just to say that this is great, and very much appreciated. There are
some threads I avoided opening (or opened from the cli) because they
started with huge attachments and I didn't feel like waiting.

I used to have something like this in my remote script, but trashed it
when I lost track of the emacs client internals, and wasn't sure anymore
what commands were called for attachments. So I'm very glad you were
moved to write this, and even gladder you posted it.

Best,
Jesse

Re: RFC: notmuch-cache.el: simple caching of MIME parts

[Jesse Rosenthal]

Hi David,

David Edmondson d...@dme.org writes:

 ...here is a very simple filesystem based cache of MIME parts for
 notmuch. It's integrated using defadvice for now, but a cleaner
 approach is obviously possible.

Just to say that this is great, and very much appreciated. There are
some threads I avoided opening (or opened from the cli) because they
started with huge attachments and I didn't feel like waiting.

I used to have something like this in my remote script, but trashed it
when I lost track of the emacs client internals, and wasn't sure anymore
what commands were called for attachments. So I'm very glad you were
moved to write this, and even gladder you posted it.

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

[PATCH] Avoid empty thread names if possible.

[Jesse Rosenthal]

Currently the thread is named based on either the oldest or newest
matching message (depending on the search order). If this message has
an empty subject, though, the thread will show up with an empty
subject in the search results. (See the thread starting with
`id:1412371140-21051-1-git-send-email-da...@tethera.net` for an
example.)

This patch changes the behavior to name based on the oldest/newest
matching non-empty subject. This is particularly helpful for patchsets.
If the only subjects are empty, the thread subject will still be empty.

Signed-off-by: Jesse Rosenthal jrosent...@jhu.edu
---
 lib/thread.cc | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/lib/thread.cc b/lib/thread.cc
index 8922403..ea10295 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -348,18 +348,20 @@ _thread_add_matched_message (notmuch_thread_t *thread,
 {
 time_t date;
 notmuch_message_t *hashed_message;
+const char *cur_subject;
 
 date = notmuch_message_get_date (message);
+cur_subject = notmuch_thread_get_subject (thread);
 
 if (date  thread-oldest || ! thread-matched_messages) {
thread-oldest = date;
-   if (sort == NOTMUCH_SORT_OLDEST_FIRST)
+   if (sort == NOTMUCH_SORT_OLDEST_FIRST || strlen(cur_subject) == 0)
_thread_set_subject_from_message (thread, message);
 }
 
 if (date  thread-newest || ! thread-matched_messages) {
thread-newest = date;
-   if (sort != NOTMUCH_SORT_OLDEST_FIRST)
+   if (sort != NOTMUCH_SORT_OLDEST_FIRST || strlen(cur_subject) == 0)
_thread_set_subject_from_message (thread, message);
 }
 
-- 
2.1.2

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

notmuch-lib questions and observations

[Jesse Rosenthal]

Tomi Valkeinen  writes:

> I think I wasn't very clear on what I meant. I was thinking about the
> behavior that graphical mail clients have: they periodically refresh the
> emails, showing new ones if there are any, and they'll show some icon or
> such which tells the user this email is "new" (which could mean received
> in the last periodic refresh).

I do something similar to what you were describing. I put two tags,
"fresh" and "new" on mails that have just come in. "fresh" is for
internal use -- it allows me to run scripts on certain mails that
haven't been checked before, and it is taken off of everything before I
see it. "new" is left on, and means that it just came in with the last
poll. This is all done as a post-new hook. Then, as  pre-new hook, I
remove all the "new" tags. So when I poll again, I only see the ones
that came in with the newest poll.

If I want to see what I've received since the last poll, I just run a
search with "tag:new AND tag:inbox."

Now, this is dones with the hooks that the command-line client uses, so
you'd have to implement it yourself for your client, but that shouldn't
be too hard.

Re: notmuch-lib questions and observations

[Jesse Rosenthal]

Tomi Valkeinen tomi.valkei...@iki.fi writes:

 I think I wasn't very clear on what I meant. I was thinking about the
 behavior that graphical mail clients have: they periodically refresh the
 emails, showing new ones if there are any, and they'll show some icon or
 such which tells the user this email is new (which could mean received
 in the last periodic refresh).

I do something similar to what you were describing. I put two tags,
fresh and new on mails that have just come in. fresh is for
internal use -- it allows me to run scripts on certain mails that
haven't been checked before, and it is taken off of everything before I
see it. new is left on, and means that it just came in with the last
poll. This is all done as a post-new hook. Then, as  pre-new hook, I
remove all the new tags. So when I poll again, I only see the ones
that came in with the newest poll.

If I want to see what I've received since the last poll, I just run a
search with tag:new AND tag:inbox.

Now, this is dones with the hooks that the command-line client uses, so
you'd have to implement it yourself for your client, but that shouldn't
be too hard.


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

Getting the right root mail of the thread

[Jesse Rosenthal]

Jani Nikula  writes:
> I think it's actually worse than what your example demonstrates. It's
> the subject of the newest/oldest *matching* message that gets used. In
> your example, the first/last messages in the thread apparently match
> your query.

The behavior is there because subjects frequently change in long
threads, and this allows the subject to refer to the most recent unread
message (if we're sorting in the default order). The 
reason I requested and wrote in this behavior five years ago or so (my
only c contribution ever) was that numerous business associates would
keep email lists by replying and changing the subject. This is *very*
common outside of programming circles. Even in programming circles,
subjects frequently change on mailing list (with a "[was: ...]"
appended). 

The current behavior can be annoying, but the old behavior could make
the MUA quite unusable in a number of circumstances. (And yes, an MUA
that fails on reading mail from senders with bad emailing practices is
unusable for me.)

Maybe there should be a "show original subject" toggle? That wouldn't be
too hard, though it would require another call to the library and
regenerating the search results.

Re: Getting the right root mail of the thread

[Jesse Rosenthal]

Jani Nikula j...@nikula.org writes:
 I think it's actually worse than what your example demonstrates. It's
 the subject of the newest/oldest *matching* message that gets used. In
 your example, the first/last messages in the thread apparently match
 your query.

The behavior is there because subjects frequently change in long
threads, and this allows the subject to refer to the most recent unread
message (if we're sorting in the default order). The 
reason I requested and wrote in this behavior five years ago or so (my
only c contribution ever) was that numerous business associates would
keep email lists by replying and changing the subject. This is *very*
common outside of programming circles. Even in programming circles,
subjects frequently change on mailing list (with a [was: ...]
appended). 

The current behavior can be annoying, but the old behavior could make
the MUA quite unusable in a number of circumstances. (And yes, an MUA
that fails on reading mail from senders with bad emailing practices is
unusable for me.)

Maybe there should be a show original subject toggle? That wouldn't be
too hard, though it would require another call to the library and
regenerating the search results.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] Restore original keybinding ('r' = reply-to-all)

[Jesse Rosenthal]

On Wed, 27 Jun 2012, David Bremner  wrote:
> My bias is probably apparent in that I pushed the original patch...

And mine in that the first thing I did in my .emacs, back in 2009 or so,
was write a reply-to-sender function, and reverse the behavior. In fact,
I just got around to using the built-in behavior in the last couple of
weeks or so.

> I think the there is potential for unfortunate mistakes with either set
> of bindings. On the one hand sending replies to unintended people can be
> very embarrassing. 

Or something close to career-threatening. If you are in an office
situation with non-technical folks, which I am, and which more and more
of our users will likely be, replying-all accidentally can be quite
dire. The deans and the chair of my department frequently send out
requests for votes or comments to the whole department or faculty. In
many cases, the information requested is ridiculously confidential for
the medium; an accidental reply-all would be -- and I'm not overstating
-- disastrous. Incidences of this are rare, because it's not the default
in most standard clients. Even those coming from mutt or gnus are likely
to be surprised.

If it's not obvious, I'm pretty strongly against Carl's roll-back.  I
could, of course, just uncomment my old correction in my .emacs, but I
think it's a change that could hurt users. Those who are more likely to
prefer the reply-all behavior are more likely to be able to change the
defaults. Those who aren't likely to change the defaults are more likely
to be bitten, badly, by a default reply-all behavior.

> On the other hand, forgetting to reply to the group can also be
> problematic.

True that. My solution to this has been to write what I call a
"smart-reply" function -- it replies-all when you want it to, and
replies-to-sender the rest of the time. It's pretty simple, and I sent
it into the list before[0], but the basic functionality is that I give
it a list of to: addresses that I will want to reply-all to by default
(essentially, my mailing lists), and those will, by default, reply
all. Others will by default be reply-to-sender. I realize this
complicates the setup a bit, but it makes everyday use quite easy.

Best,

Jesse

[0] id:"87hay8xdoe.fsf at jhu.edu"

Re: [PATCH] Restore original keybinding ('r' = reply-to-all)

[Jesse Rosenthal]

On Wed, 27 Jun 2012, David Bremner da...@tethera.net wrote:
 My bias is probably apparent in that I pushed the original patch...

And mine in that the first thing I did in my .emacs, back in 2009 or so,
was write a reply-to-sender function, and reverse the behavior. In fact,
I just got around to using the built-in behavior in the last couple of
weeks or so.

 I think the there is potential for unfortunate mistakes with either set
 of bindings. On the one hand sending replies to unintended people can be
 very embarrassing. 

Or something close to career-threatening. If you are in an office
situation with non-technical folks, which I am, and which more and more
of our users will likely be, replying-all accidentally can be quite
dire. The deans and the chair of my department frequently send out
requests for votes or comments to the whole department or faculty. In
many cases, the information requested is ridiculously confidential for
the medium; an accidental reply-all would be -- and I'm not overstating
-- disastrous. Incidences of this are rare, because it's not the default
in most standard clients. Even those coming from mutt or gnus are likely
to be surprised.

If it's not obvious, I'm pretty strongly against Carl's roll-back.  I
could, of course, just uncomment my old correction in my .emacs, but I
think it's a change that could hurt users. Those who are more likely to
prefer the reply-all behavior are more likely to be able to change the
defaults. Those who aren't likely to change the defaults are more likely
to be bitten, badly, by a default reply-all behavior.

 On the other hand, forgetting to reply to the group can also be
 problematic.

True that. My solution to this has been to write what I call a
smart-reply function -- it replies-all when you want it to, and
replies-to-sender the rest of the time. It's pretty simple, and I sent
it into the list before[0], but the basic functionality is that I give
it a list of to: addresses that I will want to reply-all to by default
(essentially, my mailing lists), and those will, by default, reply
all. Others will by default be reply-to-sender. I realize this
complicates the setup a bit, but it makes everyday use quite easy.

Best,

Jesse

[0] id:87hay8xdoe@jhu.edu

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

[PATCHv2] emacs: derive correct timestamp in FCC unique name

[Jesse Rosenthal]

Previously, the timestamp at the beginning of the FCC unique maildir
name was derived incorrectly, thanks to an integer overflow. This
changes the derivation of timestamp to use a float, and so will get
the number correct at least until 2038. (It is still formatted with
"%d" so it will show up as an integer.) Should we need to change it in
the next 26 years to take the unix millenium into account, it will be
invisible to users.

This change is mostly a question of consistency, since the unique name
is arbitrary anyway. But since most people use timestamps, and that was
the original intention here as well, we might as well.

Signed-off-by: Jesse Rosenthal 
---
 emacs/notmuch-maildir-fcc.el |7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el
index dcfbc4b..07eedba 100644
--- a/emacs/notmuch-maildir-fcc.el
+++ b/emacs/notmuch-maildir-fcc.el
@@ -140,13 +140,12 @@ will NOT be removed or replaced."
t))

 (defun notmuch-maildir-fcc-make-uniq-maildir-id ()
-   (let* ((ct (current-time))
- (timeid (+ (* (car ct) 65536) (cadr ct)))
- (microseconds (car (cdr (cdr ct
+   (let* ((ftime (float-time))
+ (microseconds (mod (* 100 ftime) 100))
  (hostname (notmuch-maildir-fcc-host-fixer system-name)))
  (setq notmuch-maildir-fcc-count (+ notmuch-maildir-fcc-count 1))
  (format "%d.%d_%d_%d.%s"
-timeid
+ftime
 (emacs-pid)
 microseconds
 notmuch-maildir-fcc-count
-- 
1.7.9.5

[PATCH] emacs: derive correct timestamp in FCC unique name

[Jesse Rosenthal]

Hi, 

thanks for thinking this through.

On Thu, 14 Jun 2012, Tomi Ollila  wrote:
> Alternatives:
>
> 1) Use current patch, filenames will have extra '-' in 2038 on 32-bit
> systems.

Well, that assumes there is still the same arithmetic operations -- the
calendar issue will probably push them to either auto-convert to float
or use bignum. But still, assuming that in 2038, people are still on
32bit machines, it seems we should minimize the amount of things that
need to be fixed. 

So I agree that...

> 2) Drop 'timeid' and replace it with (float-time) in `format` call a few
> lines in original source after the patch context below -- No idea
> how (float-time) works on 32-bit systems after 2038.

is probably the best. They'll have to deal with their time_t (again,
assuming the unlikely existence of 32bit machines then) but this doesn't
depend on their arithemetic. 

I'll send a revision to this thread.

> I suggest option #2.
>
> Tomi

Thanks again,
Jesse

[PATCH] emacs: derive correct timestamp in FCC unique name

[Jesse Rosenthal]

Previously, the timestamp at the beginning of the FCC maildir unique
maildir name was derived incorrectly, thanks to an integer
overflow. This changes the derivation of timestamp to float
arithmetic, and so gets the number correct. (It is still formatted
with "%d" so it will show up as an integer.)

This change is mostly a question of consistency, since the unique name
is arbitrary anyway. But since most people use timestamps, and that was
the original intention here as well, we might as well.

Signed-off-by: Jesse Rosenthal 
---
 emacs/notmuch-maildir-fcc.el |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el
index dcfbc4b..6fd8ff9 100644
--- a/emacs/notmuch-maildir-fcc.el
+++ b/emacs/notmuch-maildir-fcc.el
@@ -141,7 +141,7 @@ will NOT be removed or replaced."

 (defun notmuch-maildir-fcc-make-uniq-maildir-id ()
(let* ((ct (current-time))
- (timeid (+ (* (car ct) 65536) (cadr ct)))
+ (timeid (+ (* (car ct) 65536.0) (cadr ct)))
  (microseconds (car (cdr (cdr ct
  (hostname (notmuch-maildir-fcc-host-fixer system-name)))
  (setq notmuch-maildir-fcc-count (+ notmuch-maildir-fcc-count 1))
-- 
1.7.9.5

[RFC] Smart replying

[Jesse Rosenthal]

Dear All,

I know that folks recently got done haggling over reply bindings, but
there's something I've been using for a little while, and I was curious
about whether it's something people would be interested in. Forgive me
if this functionality was already discussed and I missed it.

The problem is that I often forget to reply-all to list mails and write
out half a message, and then have to cut and paste. So, as usual, my
solution is to try and have emacs figure it out for me.

Pretty simple: have a variable `reply-all-list'. If an address in the
`To' or `CC' fields is in that list, 'r' replies-all. If not, it
replies-sender. CTRL-r (or whatever) forces `reply-sender', on the rare
occasion I want to take a conversation offline.

The nice thing about this is, if `reply-all-list' is nil, then it acts
as normal, so it wouldn't make a difference to most users.

The implementation that's been sitting in my .emacs is below. I'm not
offering it as a patch, because I don't quite understand the current
relation of notmuch-show.el and notmuch-mua.el. 

If people are interested, though, I could make it into a patch. And, if
not, I hope it's a snippet that someone finds useful.

Best,
Jesse

~
(defvar reply-all-list nil)

(defun jkr/notmuch-show-check-to-cc (address-list)
  (let* ((to-cc-list (apply 'append 
(mapcar 'mail-header-parse-addresses 
(list (notmuch-show-get-to) 
  (notmuch-show-get-cc)
 (to-cc-addr-list (mapcar 'car to-cc-list)))
(intersection address-list to-cc-addr-list :test 'equal)))

(defun jkr/notmuch-show-smart-reply-all ()
  "Reply to sender, unless address is on reply-all list"
  (interactive)
  (if (jkr/notmuch-show-check-to-cc reply-all-list)
  (notmuch-show-reply)
(notmuch-show-reply-sender)))

(defun jkr/notmuch-show-force-reply-sender ()
  "Reply to sender only, regardless of reply-all list"
  (interactive)
  (notmuch-show-reply-sender))

(define-key notmuch-show-mode-map "r" 'jkr/notmuch-show-smart-reply-all)

(define-key notmuch-show-mode-map "\C-r" 'jkr/notmuch-show-force-reply-sender)

; (setq reply-all-list '("notmuch at notmuchmail.org"))

Replacing my name/email with "me" (or similar) in author lists

[Jesse Rosenthal]

On Wed, 29 Feb 2012 17:47:46 -0500, Austin Clements  wrote:
> > On Wed, 29 Feb 2012 10:36:57 -0500, Austin Clements  
> > wrote:
> > > What if the output of search (say, specifically the JSON format)
> > > included information on each message in the thread such as the
> > > 'message' production from devel/schemata minus the body field?  
> [...]
> I was suggesting just using notmuch_thread_get_toplevel_messages in
> search (essentially, mixing a bit of show into search).  No library
> changes necessary.

In any event, I'd really love to see something like this. Because I work
remotely, over an ssh tunnel, and it's nice to have various scripts
local. However, things like notmuch_addresses and my recipient_search
script have to run on the server, since they need bindings-level access
to the database. If I could get the JSON you describe over the wire, I
could probably just make one remote call and then confine my local work
to JSON parsing. A niche need, I realize.

Re: Replacing my name/email with me (or similar) in author lists

[Jesse Rosenthal]

On Wed, 29 Feb 2012 17:47:46 -0500, Austin Clements amdra...@mit.edu wrote:
  On Wed, 29 Feb 2012 10:36:57 -0500, Austin Clements amdra...@mit.edu 
  wrote:
   What if the output of search (say, specifically the JSON format)
   included information on each message in the thread such as the
   'message' production from devel/schemata minus the body field?  
 [...]
 I was suggesting just using notmuch_thread_get_toplevel_messages in
 search (essentially, mixing a bit of show into search).  No library
 changes necessary.

In any event, I'd really love to see something like this. Because I work
remotely, over an ssh tunnel, and it's nice to have various scripts
local. However, things like notmuch_addresses and my recipient_search
script have to run on the server, since they need bindings-level access
to the database. If I could get the JSON you describe over the wire, I
could probably just make one remote call and then confine my local work
to JSON parsing. A niche need, I realize.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[RFC] Smart replying

[Jesse Rosenthal]

Dear All,

I know that folks recently got done haggling over reply bindings, but
there's something I've been using for a little while, and I was curious
about whether it's something people would be interested in. Forgive me
if this functionality was already discussed and I missed it.

The problem is that I often forget to reply-all to list mails and write
out half a message, and then have to cut and paste. So, as usual, my
solution is to try and have emacs figure it out for me.

Pretty simple: have a variable `reply-all-list'. If an address in the
`To' or `CC' fields is in that list, 'r' replies-all. If not, it
replies-sender. CTRL-r (or whatever) forces `reply-sender', on the rare
occasion I want to take a conversation offline.

The nice thing about this is, if `reply-all-list' is nil, then it acts
as normal, so it wouldn't make a difference to most users.

The implementation that's been sitting in my .emacs is below. I'm not
offering it as a patch, because I don't quite understand the current
relation of notmuch-show.el and notmuch-mua.el. 

If people are interested, though, I could make it into a patch. And, if
not, I hope it's a snippet that someone finds useful.

Best,
Jesse

~
(defvar reply-all-list nil)

(defun jkr/notmuch-show-check-to-cc (address-list)
  (let* ((to-cc-list (apply 'append 
(mapcar 'mail-header-parse-addresses 
(list (notmuch-show-get-to) 
  (notmuch-show-get-cc)
 (to-cc-addr-list (mapcar 'car to-cc-list)))
(intersection address-list to-cc-addr-list :test 'equal)))

(defun jkr/notmuch-show-smart-reply-all ()
  Reply to sender, unless address is on reply-all list
  (interactive)
  (if (jkr/notmuch-show-check-to-cc reply-all-list)
  (notmuch-show-reply)
(notmuch-show-reply-sender)))

(defun jkr/notmuch-show-force-reply-sender ()
  Reply to sender only, regardless of reply-all list
  (interactive)
  (notmuch-show-reply-sender))

(define-key notmuch-show-mode-map r 'jkr/notmuch-show-smart-reply-all)

(define-key notmuch-show-mode-map \C-r 'jkr/notmuch-show-force-reply-sender)

; (setq reply-all-list '(notmuch@notmuchmail.org))


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

Replacing my name/email with "me" (or similar) in author lists

[Jesse Rosenthal]

On Wed, 29 Feb 2012 10:36:57 -0500, Austin Clements  wrote:
> What if the output of search (say, specifically the JSON format)
> included information on each message in the thread such as the
> 'message' production from devel/schemata minus the body field?  Then
> the frontend would have loads of information it could produce its own
> summaries from.  (Plus, with a little tweaking, I don't think this
> would be any more expensive than producing the current notmuch search
> summary output.)

I was hoping for something like that when I started fiddling. But it's
still going to end up being a library question, because
notmuch-search.c, is tied pretty tightly to the lib: i.e. it uses
functions like `notmuch_thread_get_authors (thread)'. I was using the
python bindings, and I ended up having to make a second query off the
thread id (I could have recursed through the messages too, I suppose).

So I guess what I'm saying is that what you're suggesting sounds great,
but we'd still have to either (a) add new library functions
(`notmuch_thread_get_recipients', `notmuch_thread_abbrev_me'), (b) keep
them all in the client and make pazz and scripters recreate them, or (c)
play around in the sort of client-library space that it sounded like
Bremner was suggesting.

Best,
Jesse

Replacing my name/email with "me" (or similar) in author lists

[Jesse Rosenthal]

On Sun, 26 Feb 2012 16:59:53 -0500, Tom Prince  
wrote:
> It is probably overkill for any one feature, but it does seem like
> something useful to have. So maybe it would be worthwhile to create
> for this one feature, even it it is overkill.

I can think of other features where some layer like this would be
useful. It would be great, for example, if it were possible to output
search lines with recipients instead of senders, for the purposes of a
"tag:sent" sort of window. 

(I actually have my own cobbled-together python thing which, connected
with my other cobbled-together python remote thing, intercepts search
calls for that tag and gives me a search view with non-me
recipients. But obviously, as much as I love cobbling, it would be even
better not to have to do that.)

Best,
Jesse

Re: Replacing my name/email with me (or similar) in author lists

[Jesse Rosenthal]

On Sun, 26 Feb 2012 16:59:53 -0500, Tom Prince tom.pri...@ualberta.net wrote:
 It is probably overkill for any one feature, but it does seem like
 something useful to have. So maybe it would be worthwhile to create
 for this one feature, even it it is overkill.

I can think of other features where some layer like this would be
useful. It would be great, for example, if it were possible to output
search lines with recipients instead of senders, for the purposes of a
tag:sent sort of window. 

(I actually have my own cobbled-together python thing which, connected
with my other cobbled-together python remote thing, intercepts search
calls for that tag and gives me a search view with non-me
recipients. But obviously, as much as I love cobbling, it would be even
better not to have to do that.)

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

Re: Replacing my name/email with me (or similar) in author lists

[Jesse Rosenthal]

On Wed, 29 Feb 2012 10:36:57 -0500, Austin Clements amdra...@mit.edu wrote:
 What if the output of search (say, specifically the JSON format)
 included information on each message in the thread such as the
 'message' production from devel/schemata minus the body field?  Then
 the frontend would have loads of information it could produce its own
 summaries from.  (Plus, with a little tweaking, I don't think this
 would be any more expensive than producing the current notmuch search
 summary output.)

I was hoping for something like that when I started fiddling. But it's
still going to end up being a library question, because
notmuch-search.c, is tied pretty tightly to the lib: i.e. it uses
functions like `notmuch_thread_get_authors (thread)'. I was using the
python bindings, and I ended up having to make a second query off the
thread id (I could have recursed through the messages too, I suppose).

So I guess what I'm saying is that what you're suggesting sounds great,
but we'd still have to either (a) add new library functions
(`notmuch_thread_get_recipients', `notmuch_thread_abbrev_me'), (b) keep
them all in the client and make pazz and scripters recreate them, or (c)
play around in the sort of client-library space that it sounded like
Bremner was suggesting.

Best,
Jesse

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

nomuch_addresses.py

[Jesse Rosenthal]

On Tue, 21 Feb 2012 14:53:06 +0100, Daniel Schoepe  
wrote:
> On Tue, 21 Feb 2012 09:15:09 -, Justus Winter <4winter at 
> informatik.uni-hamburg.de> wrote:
> The reason I mentioned nottoomuch-addresses at all, is that completion
> itself is _a lot_ faster (at least for me), compared to
> addrlookup. According to the wiki, notmuch-addresses.py is even slower
> than addrlookup, so I thought (and still think) that it was worth
> mentioning. Of course, one could rewrite the database-generation part in
> python using the bindings, but I personally don't think it's that
> necessary.

I'm not sure what speed comparisons were being used -- I think it was
Sebastian comparing vala to python. In any case, using
notmuch_addresses.py to look up a common prefix ("Jes") on a slowish
computer takes 0.2 seconds. So I'm not sure if the speed is all that
much of an issue. It might be a question of cache temperature, though --
it'll probably take longer the first time you run it. Still, even trying
something out on a cold cache, it seems to be about a second.

I guess the question is whether having a second database is worth those
extra fractions of a second. I could totally see how it would be for
some.

Re: nomuch_addresses.py

[Jesse Rosenthal]

On Tue, 21 Feb 2012 14:53:06 +0100, Daniel Schoepe dan...@schoepe.org wrote:
 On Tue, 21 Feb 2012 09:15:09 -, Justus Winter 
 4win...@informatik.uni-hamburg.de wrote:
 The reason I mentioned nottoomuch-addresses at all, is that completion
 itself is _a lot_ faster (at least for me), compared to
 addrlookup. According to the wiki, notmuch-addresses.py is even slower
 than addrlookup, so I thought (and still think) that it was worth
 mentioning. Of course, one could rewrite the database-generation part in
 python using the bindings, but I personally don't think it's that
 necessary.

I'm not sure what speed comparisons were being used -- I think it was
Sebastian comparing vala to python. In any case, using
notmuch_addresses.py to look up a common prefix (Jes) on a slowish
computer takes 0.2 seconds. So I'm not sure if the speed is all that
much of an issue. It might be a question of cache temperature, though --
it'll probably take longer the first time you run it. Still, even trying
something out on a cold cache, it seems to be about a second.

I guess the question is whether having a second database is worth those
extra fractions of a second. I could totally see how it would be for
some.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

nomuch_addresses.py

[Jesse Rosenthal]

On Thu, 16 Feb 2012 14:51:59 -0500, Philippe LeCavalier  wrote:
> $ ~/notmuch/notmuch_addresses/notmuch_addresses.py
> Traceback (most recent call last):
>   File "/home/plecavalier/notmuch/notmuch_addresses/notmuch_addresses.py", 
> line 19, in 
> import notmuch
> ImportError: No module named notmuch

Well, there's your problem. You need the notmuch python bindings. They
should be available from your distro repository, or in the bindings/
directory if you installed from source.

Best,
Jesse

nomuch_addresses.py

[Jesse Rosenthal]

On Thu, 16 Feb 2012 14:12:36 -0500, Philippe LeCavalier  wrote:
> I'm trying to setup tab completion for addresses. I appeared to me that
> the simplest solution was notmuch_addresses so I grabbed a copy from
> git. When I hit tab I get this[1] Was I suppose to do something more?
...
> ref.
> [1]
> ~/notmuch/notmuch_addresses/notmuch_addresses.py exited with status 1

I'd hope so. What happens when you run it from the command line?

Best,
Jesse

Re: nomuch_addresses.py

[Jesse Rosenthal]

On Thu, 16 Feb 2012 14:12:36 -0500, Philippe LeCavalier 
supp...@plecavalier.com wrote:
 I'm trying to setup tab completion for addresses. I appeared to me that
 the simplest solution was notmuch_addresses so I grabbed a copy from
 git. When I hit tab I get this[1] Was I suppose to do something more?
...
 ref.
 [1]
 ~/notmuch/notmuch_addresses/notmuch_addresses.py exited with status 1

I'd hope so. What happens when you run it from the command line?

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

Re: nomuch_addresses.py

[Jesse Rosenthal]

On Thu, 16 Feb 2012 14:51:59 -0500, Philippe LeCavalier 
supp...@plecavalier.com wrote:
 $ ~/notmuch/notmuch_addresses/notmuch_addresses.py
 Traceback (most recent call last):
   File /home/plecavalier/notmuch/notmuch_addresses/notmuch_addresses.py, 
 line 19, in module
 import notmuch
 ImportError: No module named notmuch

Well, there's your problem. You need the notmuch python bindings. They
should be available from your distro repository, or in the bindings/
directory if you installed from source.

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

newbie questions

[Jesse Rosenthal]

On Mon, 06 Feb 2012 08:51:15 +0200, Tomi Ollila  wrote:
> On Fri, 3 Feb 2012 12:59:34 +0100, Tamas Papp  wrote:
> > 
> > 1. How can I restrict searches (eg of my inbox) to the last few
> > messages (eg 50-100) or some date (eg last 2 weeks)?  I am using the
> > Emacs interface.
> 
> Currently, if you have GNU date you can run from command line:
> 
> date +%s.. --date '2 weeks ago'
> 
> Then paste the string 1327300096.. to the search field.

FWIW, I actually have a hacky date parser baked into my
remote-usage-and-other-stuff script (a more idiosyncratc python
version of the bash script on the wiki). I found that I needed
date-searching pretty frequently, since language and senders seem to be
repeated pretty often in my world. It just parses a "date:" term, passes
it to GNU date, and proceeds with a term in notmuch language. It also
does some day-rounding, since by "date:'2 days ago'..yesterday", I mean
"beginning of day before yesterday to end of yesterday," not "48 hours
ago until 24 hours ago."

I'm not swearing by its efficiency, or even its correctness, but it has
made my life easier. The basics are as follows:

DATE_PATTERN = re.compile(r'^date:([^.]+)(\.\.)?([^.]+)?')

def replace_date_args(st):
out = subprocess.check_output([GNU_DATE, "+%s", "-d", st])
return out.strip()

def round_day_down(timestamp):
tup = datetime.fromtimestamp(int(timestamp)).date().timetuple()
return time.mktime(tup)

def round_day_up(timestamp):
date = datetime.fromtimestamp(int(timestamp)).date()
date += timedelta(days=1)
tup = date.timetuple()
return time.mktime(tup)

def parse_date_args(st):
re_match = DATE_PATTERN.match(st)
if re_match:
grps = re_match.groups()
start_term = grps[0]
if not (grps[1] or grps[2]):
stop_term = start_term
elif not grps[2]:
stop_term = "now"
else:
stop_term = grps[2]

try:
start = round_day_down(replace_date_args(start_term))
stop = round_day_up(replace_date_args(stop_term))
return "%d..%d" % (start, stop)
except OSError:
return st
else:
return st

And then in the main routine, I have a parse-and-replace step:

args = sys.argv[1:]
try:
if args[-1] == ")'":
args = args[:-2] + shlex.split(sys.argv[-2]) + [")'"]
else:
args = args[:-1] + shlex.split(sys.argv[-1])
except IndexError, ValueError:
pass

args = [parse_date_args(a) for a in args] 

I'm only giving the relevant parts here, of course.

Best,
Jesse

Re: newbie questions

[Jesse Rosenthal]

On Mon, 06 Feb 2012 08:51:15 +0200, Tomi Ollila tomi.oll...@iki.fi wrote:
 On Fri, 3 Feb 2012 12:59:34 +0100, Tamas Papp tkp...@gmail.com wrote:
  
  1. How can I restrict searches (eg of my inbox) to the last few
  messages (eg 50-100) or some date (eg last 2 weeks)?  I am using the
  Emacs interface.
 
 Currently, if you have GNU date you can run from command line:
 
 date +%s.. --date '2 weeks ago'
 
 Then paste the string 1327300096.. to the search field.

FWIW, I actually have a hacky date parser baked into my
remote-usage-and-other-stuff script (a more idiosyncratc python
version of the bash script on the wiki). I found that I needed
date-searching pretty frequently, since language and senders seem to be
repeated pretty often in my world. It just parses a date: term, passes
it to GNU date, and proceeds with a term in notmuch language. It also
does some day-rounding, since by date:'2 days ago'..yesterday, I mean
beginning of day before yesterday to end of yesterday, not 48 hours
ago until 24 hours ago.

I'm not swearing by its efficiency, or even its correctness, but it has
made my life easier. The basics are as follows:

DATE_PATTERN = re.compile(r'^date:([^.]+)(\.\.)?([^.]+)?')

def replace_date_args(st):
out = subprocess.check_output([GNU_DATE, +%s, -d, st])
return out.strip()

def round_day_down(timestamp):
tup = datetime.fromtimestamp(int(timestamp)).date().timetuple()
return time.mktime(tup)

def round_day_up(timestamp):
date = datetime.fromtimestamp(int(timestamp)).date()
date += timedelta(days=1)
tup = date.timetuple()
return time.mktime(tup)

def parse_date_args(st):
re_match = DATE_PATTERN.match(st)
if re_match:
grps = re_match.groups()
start_term = grps[0]
if not (grps[1] or grps[2]):
stop_term = start_term
elif not grps[2]:
stop_term = now
else:
stop_term = grps[2]

try:
start = round_day_down(replace_date_args(start_term))
stop = round_day_up(replace_date_args(stop_term))
return %d..%d % (start, stop)
except OSError:
return st
else:
return st

And then in the main routine, I have a parse-and-replace step:

args = sys.argv[1:]
try:
if args[-1] == )':
args = args[:-2] + shlex.split(sys.argv[-2]) + [)']
else:
args = args[:-1] + shlex.split(sys.argv[-1])
except IndexError, ValueError:
pass

args = [parse_date_args(a) for a in args] 

I'm only giving the relevant parts here, of course.

Best,
Jesse


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

tach.el: an attachment interface for message mode.

[Jesse Rosenthal]

Hi Xavier,

On Fri, 20 Jan 2012 23:43:01 +0100, Xavier Maillard  
wrote:

> I like it.
Thanks for giving it a try.

> Simple but at first it is not easy to understand what to do with that
> window. Also, there is no way to toggle the window visibility. But for a
> first shot, it is a good shot :D

There could be a prompt in the minibuffer, I suppose, or the blank
second window could have a prompt in it as well.  And it would actually
be easy enough to add that toggle, since the window is really just a
different sort of view on a numerical list at the bottom of the
page. I'll give it a shot soon.

> I tried it by adding tach.el to myself. When sending the message, I have
> been asked whether I'd like to update copyright date and change licence
> to GPL3, huh ? Is this something specific to how tach.el works ?

I actually have no idea what this could come from. The date is a couple
of years back, and the license is GPL2+. I'm not sure why it would
prompt you to change that. Ever come across this before?

Best, 
Jesse

tach.el: an attachment interface for message mode.

[Jesse Rosenthal]

Dear All,

I sent this to the list a couple of years back, but now that things are
moving again, and there are new eyes on the list, I thought I'd send it
again. I believe I'm the only person to use this (and might well
continue to be so) but I've been using it for a couple of years without
any problems, and it has made using message mode a lot more
convenient. As far as I know, this doesn't intersect with the recent
security problems pointed out in mml-mode, but I could be wrong.

My issue was this: the handling of (outgoing) attachments in
message-mode left a lot to be desired. MML's markup can be confusing,
and can easily be edited by mistake.

Thus: tach.el. Tach is a minor mode that adds mutt-like attachment
handling to message mode. It's not notmuch specific, but I wrote it to
use with notmuch, and I thought it might be of use to some on the
list.

You can find tach.el attached to this email.

To use tach, put tach.el in your load-path, and add the following to
your .emacs:

(require 'tach)
(add-hook 'message-mode-hook 'tach-minor-mode)

Now when you type "C-c C-a" in message-mode, you should get a new window
with an attachment list. In that window, you can add and delete
attachments using `+' and `-', and scroll through them using the arrow
keys or the emacs direction commands.

tach.el will convert the attachments into MML markup as a last
step before sending. Hopefully you should never have to deal with it by
hand.

Some details: tach actually makes a numerical list at the bottom of the
message itself, separated by a custom separator. The message is narrowed
to above this separator, and the attachment window is an indirect buffer
narrowed to the region below the separator. The separator is erased when
the messages are translated to mml markup at the end.

This has remained at its earliest stages, and the usual disclaimers
apply. It certainly needs more a lot more commenting and
documentation. But I thought it might be useful, or at least fun to play
around with. And it might fill a niche for some users, as notmuch's
popularity continues to grow.

Best,
Jesse


-- next part --
A non-text attachment was scrubbed...
Name: tach.el
Type: application/emacs-lisp
Size: 9481 bytes
Desc: not available
URL: 

tach.el: an attachment interface for message mode.

[Jesse Rosenthal]

Dear All,

I sent this to the list a couple of years back, but now that things are
moving again, and there are new eyes on the list, I thought I'd send it
again. I believe I'm the only person to use this (and might well
continue to be so) but I've been using it for a couple of years without
any problems, and it has made using message mode a lot more
convenient. As far as I know, this doesn't intersect with the recent
security problems pointed out in mml-mode, but I could be wrong.

My issue was this: the handling of (outgoing) attachments in
message-mode left a lot to be desired. MML's markup can be confusing,
and can easily be edited by mistake.

Thus: tach.el. Tach is a minor mode that adds mutt-like attachment
handling to message mode. It's not notmuch specific, but I wrote it to
use with notmuch, and I thought it might be of use to some on the
list.

You can find tach.el attached to this email.

To use tach, put tach.el in your load-path, and add the following to
your .emacs:

(require 'tach)
(add-hook 'message-mode-hook 'tach-minor-mode)

Now when you type C-c C-a in message-mode, you should get a new window
with an attachment list. In that window, you can add and delete
attachments using `+' and `-', and scroll through them using the arrow
keys or the emacs direction commands.

tach.el will convert the attachments into MML markup as a last
step before sending. Hopefully you should never have to deal with it by
hand.

Some details: tach actually makes a numerical list at the bottom of the
message itself, separated by a custom separator. The message is narrowed
to above this separator, and the attachment window is an indirect buffer
narrowed to the region below the separator. The separator is erased when
the messages are translated to mml markup at the end.

This has remained at its earliest stages, and the usual disclaimers
apply. It certainly needs more a lot more commenting and
documentation. But I thought it might be useful, or at least fun to play
around with. And it might fill a niche for some users, as notmuch's
popularity continues to grow.

Best,
Jesse




tach.el
Description: application/emacs-lisp
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: tach.el: an attachment interface for message mode.

[Jesse Rosenthal]

Hi Xavier,

On Fri, 20 Jan 2012 23:43:01 +0100, Xavier Maillard xav...@maillard.im wrote:

 I like it.
Thanks for giving it a try.

 Simple but at first it is not easy to understand what to do with that
 window. Also, there is no way to toggle the window visibility. But for a
 first shot, it is a good shot :D

There could be a prompt in the minibuffer, I suppose, or the blank
second window could have a prompt in it as well.  And it would actually
be easy enough to add that toggle, since the window is really just a
different sort of view on a numerical list at the bottom of the
page. I'll give it a shot soon.

 I tried it by adding tach.el to myself. When sending the message, I have
 been asked whether I'd like to update copyright date and change licence
 to GPL3, huh ? Is this something specific to how tach.el works ?

I actually have no idea what this could come from. The date is a couple
of years back, and the license is GPL2+. I'm not sure why it would
prompt you to change that. Ever come across this before?

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

Updated remote script

[Jesse Rosenthal]

Hi Tomi,

On Thu, 19 Jan 2012 19:50:38 +0200, Tomi Ollila  wrote:
> Quick comments: "/tmp/notmuch_dtach.socket" is dangerous (and the _ssh).
> 
> either
> make directory /tmp/notmuch_`id -u`
> and chmod it to 0700
> and make sure you own it and it has right permissions.
> or
> make directory for these sockets in $HOME and chmod that to 700
> or
> just drop the socket in $HOME/.ssh (which should already be
> protected)

Thanks very much for that. I made some quick changes, based on your
first suggestion above. I'm pretty sure the checks are not in the most
optimal order, but it seemed worth getting the changes up.

As always, of course, anyone is more than welcome to change and improve
the version up there. I was mainly changing it just to get my last
error-ridden version out of circulation.

Thanks again,
Jesse

Updated remote script

[Jesse Rosenthal]

Dear all,

Just wanted to note that I finally got around to updating the
way-deprecated "remoteusage" wiki page[0], with a simplified
script, that takes into account comments that some have made in the
past.

Caching for attachments is gone, since the complications of part
handling vs. raw handling seems to have made it more trouble than it was
worth at the moment. (And because I do most of my work on a
well-connected machine.)

The big change in this script is that it uses dtach to set up a ssh
socket, rather than suggesting that users do so themselves with the
ControlMaster configuration option. This has the benefit of not making
anyone mess with ~/.ssh, and not impacting your other ssh work. It also
handles the issues of dead sockets on a laptop. (`ssh -Nf` seems like it
*should* work too, but emacs hangs when it is used in a script.) The
problem with this approach, of course, is that it requires dtach. A good
solution would be to (a) make the use of reusable ssh sockets optional,
and (b) allow it to use screen or tmux instead of dtach. Both would be
pretty easy, and I'll work on it at some point. But I figured getting a
two-year-old, broken script of the wiki would be a good first step.

[0] http://notmuchmail.org/remoteusage/

Best,
Jesse

Updated remote script

[Jesse Rosenthal]

Dear all,

Just wanted to note that I finally got around to updating the
way-deprecated remoteusage wiki page[0], with a simplified
script, that takes into account comments that some have made in the
past.

Caching for attachments is gone, since the complications of part
handling vs. raw handling seems to have made it more trouble than it was
worth at the moment. (And because I do most of my work on a
well-connected machine.)

The big change in this script is that it uses dtach to set up a ssh
socket, rather than suggesting that users do so themselves with the
ControlMaster configuration option. This has the benefit of not making
anyone mess with ~/.ssh, and not impacting your other ssh work. It also
handles the issues of dead sockets on a laptop. (`ssh -Nf` seems like it
*should* work too, but emacs hangs when it is used in a script.) The
problem with this approach, of course, is that it requires dtach. A good
solution would be to (a) make the use of reusable ssh sockets optional,
and (b) allow it to use screen or tmux instead of dtach. Both would be
pretty easy, and I'll work on it at some point. But I figured getting a
two-year-old, broken script of the wiki would be a good first step.

[0] http://notmuchmail.org/remoteusage/

Best,
Jesse

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

Re: Updated remote script

[Jesse Rosenthal]

Hi Tomi,

On Thu, 19 Jan 2012 19:50:38 +0200, Tomi Ollila tomi.oll...@iki.fi wrote:
 Quick comments: /tmp/notmuch_dtach.socket is dangerous (and the _ssh).
 
 either
 make directory /tmp/notmuch_`id -u`
 and chmod it to 0700
 and make sure you own it and it has right permissions.
 or
 make directory for these sockets in $HOME and chmod that to 700
 or
 just drop the socket in $HOME/.ssh (which should already be
 protected)

Thanks very much for that. I made some quick changes, based on your
first suggestion above. I'm pretty sure the checks are not in the most
optimal order, but it seemed worth getting the changes up.

As always, of course, anyone is more than welcome to change and improve
the version up there. I was mainly changing it just to get my last
error-ridden version out of circulation.

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

[PATCH] Perform mail polling asynchronously

[Jesse Rosenthal]

On Tue, 03 Jan 2012 16:02:43 +, David Edmondson  wrote:
> On Mon,  5 Sep 2011 07:14:36 +0300, Antono Vasiljev  
> wrote:
>
> If the poll script runs asynchronously, won't the notmuch-search output
> refresh and jump into my face when I'm busy doing something else? And,
> if I'm not busy doing something else, why can't I just wait for the poll
> script to complete?

Well, he might have dropped it (and notmuch), but I've been wondering
about the possibilities of this for the emacs client. What I was
imagining was some sort of modeline notifier, like what ERC offers. It
could easily alert you without jumping into your face.

Just musing -- I haven't had time to actually think it all the way
through.

--J

Re: [PATCH] Perform mail polling asynchronously

[Jesse Rosenthal]

On Tue, 03 Jan 2012 16:02:43 +, David Edmondson d...@dme.org wrote:
 On Mon,  5 Sep 2011 07:14:36 +0300, Antono Vasiljev s...@antono.info wrote:

 If the poll script runs asynchronously, won't the notmuch-search output
 refresh and jump into my face when I'm busy doing something else? And,
 if I'm not busy doing something else, why can't I just wait for the poll
 script to complete?

Well, he might have dropped it (and notmuch), but I've been wondering
about the possibilities of this for the emacs client. What I was
imagining was some sort of modeline notifier, like what ERC offers. It
could easily alert you without jumping into your face.

Just musing -- I haven't had time to actually think it all the way
through.

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

[PATCH] notmuch-addresses: Match on the full name as well as components.

[Jesse Rosenthal]

Oh, and I moved the code to

http://commonmeasure.org/~jkr/notmuch_addresses.git

Best,
Jesse

On Fri, 30 Dec 2011 14:04:43 -0500, Jesse Rosenthal  
wrote:
> Pushed.
> 
> Thanks,
> Jesse
> 
> On Wed, 21 Dec 2011 13:49:17 +, David Edmondson  wrote:
> > ---
> >  notmuch_addresses.py |7 +--
> >  1 files changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/notmuch_addresses.py b/notmuch_addresses.py
> > index bf45151..74a743c 100755
> > --- a/notmuch_addresses.py
> > +++ b/notmuch_addresses.py
> > @@ -164,11 +164,14 @@ class NotmuchAddressMatcher(object):
> >  addrs.append(v)
> >  parsed_addrs = email.utils.getaddresses(addrs)
> >  for addr in parsed_addrs:
> > -mail = addr[1].lower()
> > -split_names = addr[0].split(" ")
> > +full_name = addr[0]
> > +split_names = full_name.split(" ")
> > +mail = addr[1]
> >  if (len([name for name in split_names 
> >   if self.match_function(name)]) > 0
> >  or 
> > +self.match_function(full_name)
> > +or 
> >  self.match_function(mail)):
> >  
> >  emails.add_email_and_name(mail, addr[0])
> > -- 
> > 1.7.7.3
> > 

[PATCH] notmuch-addresses: Match on the full name as well as components.

[Jesse Rosenthal]

Pushed.

Thanks,
Jesse

On Wed, 21 Dec 2011 13:49:17 +, David Edmondson  wrote:
> ---
>  notmuch_addresses.py |7 +--
>  1 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/notmuch_addresses.py b/notmuch_addresses.py
> index bf45151..74a743c 100755
> --- a/notmuch_addresses.py
> +++ b/notmuch_addresses.py
> @@ -164,11 +164,14 @@ class NotmuchAddressMatcher(object):
>  addrs.append(v)
>  parsed_addrs = email.utils.getaddresses(addrs)
>  for addr in parsed_addrs:
> -mail = addr[1].lower()
> -split_names = addr[0].split(" ")
> +full_name = addr[0]
> +split_names = full_name.split(" ")
> +mail = addr[1]
>  if (len([name for name in split_names 
>   if self.match_function(name)]) > 0
>  or 
> +self.match_function(full_name)
> +or 
>  self.match_function(mail)):
>  
>  emails.add_email_and_name(mail, addr[0])
> -- 
> 1.7.7.3
> 

Re: [PATCH] notmuch-addresses: Match on the full name as well as components.

[Jesse Rosenthal]

Oh, and I moved the code to

http://commonmeasure.org/~jkr/notmuch_addresses.git

Best,
Jesse

On Fri, 30 Dec 2011 14:04:43 -0500, Jesse Rosenthal jrosent...@jhu.edu wrote:
 Pushed.
 
 Thanks,
 Jesse
 
 On Wed, 21 Dec 2011 13:49:17 +, David Edmondson d...@dme.org wrote:
  ---
   notmuch_addresses.py |7 +--
   1 files changed, 5 insertions(+), 2 deletions(-)
  
  diff --git a/notmuch_addresses.py b/notmuch_addresses.py
  index bf45151..74a743c 100755
  --- a/notmuch_addresses.py
  +++ b/notmuch_addresses.py
  @@ -164,11 +164,14 @@ class NotmuchAddressMatcher(object):
   addrs.append(v)
   parsed_addrs = email.utils.getaddresses(addrs)
   for addr in parsed_addrs:
  -mail = addr[1].lower()
  -split_names = addr[0].split( )
  +full_name = addr[0]
  +split_names = full_name.split( )
  +mail = addr[1]
   if (len([name for name in split_names 
if self.match_function(name)])  0
   or 
  +self.match_function(full_name)
  +or 
   self.match_function(mail)):
   
   emails.add_email_and_name(mail, addr[0])
  -- 
  1.7.7.3
  
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: remote-notmuch.sh

[Jesse Rosenthal]

Hi Tomi,

 If this proves to be working better in other users use then I can
 update the script on the remoteusage page also.

I actually wrote the original script, and updated it as I changed it,
without much sense for who, if anyone, was using it. Please feel free to
update the version on the official wiki as you see fit. It's stagnated,
I think, because recently I've been playing around with alternate
methods (some zeromq/paramiko monstrosity that I built mainly as an
exercise in other stuff, but which works well enough that I haven't had
cause to switch back in a while).

Of course, if anyone else is using the script and has an objection, they
should chime in.

Best,
Jesse



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

remote-notmuch.sh

[Jesse Rosenthal]

Hi Tomi,

> If this proves to be working better in other users use then I can
> update the script on the remoteusage page also.

I actually wrote the original script, and updated it as I changed it,
without much sense for who, if anyone, was using it. Please feel free to
update the version on the official wiki as you see fit. It's stagnated,
I think, because recently I've been playing around with alternate
methods (some zeromq/paramiko monstrosity that I built mainly as an
exercise in other stuff, but which works well enough that I haven't had
cause to switch back in a while).

Of course, if anyone else is using the script and has an objection, they
should chime in.

Best,
Jesse

tag sharing

[Jesse Rosenthal]

On Fri, 07 Oct 2011 07:36:30 -0400, Jesse Rosenthal  
wrote:
> What's the value added over just keeping a (compressed?) collection of
> diffs for each namespace?

Okay -- please don't bother answering this part. It was early in the
morning, and I forgot some of the obvious advantages of real version
control (we can roll back to a previous moment, etc). We still don't
need most of what git offers, but if it's the best tool for keeping
track of the move from the file in step (5) to the file in step (6),
then sure, let's use it.

tag sharing

[Jesse Rosenthal]

On Thu, 06 Oct 2011 11:18:51 -0300, David Bremner  wrote:
Non-text part: multipart/signed
> On Thu, 06 Oct 2011 09:21:48 -0400, Jesse Rosenthal  
> wrote:
> > morning's project. In retrospect, I think the main issue was that I was
> > trying to figure out how history would be kept. By using git, though,
> > your idea would be that we get history for free, right?
> 
> Yeah. Of course, one would have to decide if the history of the current
> dump file format is intelligible, or if some alternative format should
> be used.

I've managed to reconstruct a bit of my thinking. I think it could work
with the current format if we went as follows. I also think we could use
git, but I'm not sure that wouldn't be overkill. Some of the steps are
in extreme slow motion, just to make sure we're on the same page. (I've
also replaced the real msg-ids to cut down on noise).

  1. David dumps the targeted messages (tags in namespace "my"), so we
 get a file like this:

  msg-id-1 at example.1 (my.foo inbox)
  msg-id-2 at example.2 (answered my.to-do inbox signed)

  2. David strips out everything but tags in the namespace and removes
 the namespace:

  msg-id-1 at example.1 (foo)
  msg-id-2 at example.2 (to-do)

  3. David makes it available, Jesse pulls.

  4. Jesse dumps the namespace he has associated with David ("bremner"):

  msg-id-3 at example.3 (bremner.bar)
  msg-id-4 at example.4 (bremner.bar unread)
  msg-id-1 at example.1 (bremner.foo inbox)
  msg-id-5 at example.5 (bremner.wishlist inbox)

  5. Jesse strips the tags:

  msg-id-3 at example.3 (bar)
  msg-id-4 at example.4 (bar)
  msg-id-1 at example.1 (foo)
  msg-id-5 at example.5 (wishlist)

  6. Jesse replaces this list with David's:

  msg-id-1 at example.1 (foo)
  msg-id-2 at example.2 (to-do)

  7. Jesse removes all tags with the "bremner" namespace from his
 database.

  8. Jesse adds the tags from the list in step (6), with the appropriate
 namespace, to his list of tags. The messages of interest now look like:

  msg-id-3 at example.3 ()
  msg-id-4 at example.4 (unread)
  msg-id-1 at example.1 (bremner.foo inbox)
  msg-id-5 at example.5 (inbox)
  msg-id-2 at example.2 (bremner.to-do someothertag)

  9. Jesse runs `notmuch restore`

The reason I went through this slowly is to highlight the fact that the
only thing that needs to be recorded in diffs somehow (in git, let's
say) are the files in steps (5) and (6). So if we integrated this with
git, there would be something along the lines of a commit (on Jesse's
computer) in step (5) and then another commit (again on Jesse's
computer) in step (6). 

Note that we don't actually need (5) to do tag-sharing. The only reason
it's there is for keeping history.

I'm pretty sure that we don't need a commit on David's computer in step
(1), because what the history would record is when the tag-sharing
utility changed your tags, not when you did.

Note also that all we would really be asking git to do here is keep an
ordered collection of diffs of a single file. Honest question: since
this is the barest possible form of version control, is git necessary?
Some of the features, like commit messages, don't seem to fit well with
this model; and others, like branching, seem pretty useless. What's the
value added over just keeping a (compressed?) collection of diffs for
each namespace?

Best,
Jesse

output file argument to notmuch dump.

[Jesse Rosenthal]

On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner  wrote:
> 1) just delete the output file option from notmuch-dump, and use shell
>redirection. So far I don't see a non-contrived example when writing
>an output file directly is useful, but maybe that is just a failure
>of imagination.
> 
> 2) delete the output file option and a global "--write" option that 
>calls freopen(... stdout). As a bonus(?) this would work for any 
>notmuch command.

Either of these seem like the right approach to me. I might favor (1)
just a bit so I don't have to choose between different ways of doing the
same thing, but that's a small point. As Jamie said, they're pretty
much the same.

--Jesse

Re: output file argument to notmuch dump.

[Jesse Rosenthal]

On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner brem...@unb.ca wrote:
 1) just delete the output file option from notmuch-dump, and use shell
redirection. So far I don't see a non-contrived example when writing
an output file directly is useful, but maybe that is just a failure
of imagination.
 
 2) delete the output file option and a global --write option that 
calls freopen(... stdout). As a bonus(?) this would work for any 
notmuch command.

Either of these seem like the right approach to me. I might favor (1)
just a bit so I don't have to choose between different ways of doing the
same thing, but that's a small point. As Jamie said, they're pretty
much the same.

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

Re: tag sharing

[Jesse Rosenthal]

On Thu, 06 Oct 2011 11:18:51 -0300, David Bremner da...@tethera.net wrote:
Non-text part: multipart/signed
 On Thu, 06 Oct 2011 09:21:48 -0400, Jesse Rosenthal jrosent...@jhu.edu 
 wrote:
  morning's project. In retrospect, I think the main issue was that I was
  trying to figure out how history would be kept. By using git, though,
  your idea would be that we get history for free, right?
 
 Yeah. Of course, one would have to decide if the history of the current
 dump file format is intelligible, or if some alternative format should
 be used.

I've managed to reconstruct a bit of my thinking. I think it could work
with the current format if we went as follows. I also think we could use
git, but I'm not sure that wouldn't be overkill. Some of the steps are
in extreme slow motion, just to make sure we're on the same page. (I've
also replaced the real msg-ids to cut down on noise).

  1. David dumps the targeted messages (tags in namespace my), so we
 get a file like this:
  
  msg-id-1@example.1 (my.foo inbox)
  msg-id-2@example.2 (answered my.to-do inbox signed)

  2. David strips out everything but tags in the namespace and removes
 the namespace:

  msg-id-1@example.1 (foo)
  msg-id-2@example.2 (to-do)

  3. David makes it available, Jesse pulls.

  4. Jesse dumps the namespace he has associated with David (bremner):

  msg-id-3@example.3 (bremner.bar)
  msg-id-4@example.4 (bremner.bar unread)
  msg-id-1@example.1 (bremner.foo inbox)
  msg-id-5@example.5 (bremner.wishlist inbox)

  5. Jesse strips the tags:

  msg-id-3@example.3 (bar)
  msg-id-4@example.4 (bar)
  msg-id-1@example.1 (foo)
  msg-id-5@example.5 (wishlist)

  6. Jesse replaces this list with David's:

  msg-id-1@example.1 (foo)
  msg-id-2@example.2 (to-do)

  7. Jesse removes all tags with the bremner namespace from his
 database.

  8. Jesse adds the tags from the list in step (6), with the appropriate
 namespace, to his list of tags. The messages of interest now look like:

  msg-id-3@example.3 ()
  msg-id-4@example.4 (unread)
  msg-id-1@example.1 (bremner.foo inbox)
  msg-id-5@example.5 (inbox)
  msg-id-2@example.2 (bremner.to-do someothertag)

  9. Jesse runs `notmuch restore`

The reason I went through this slowly is to highlight the fact that the
only thing that needs to be recorded in diffs somehow (in git, let's
say) are the files in steps (5) and (6). So if we integrated this with
git, there would be something along the lines of a commit (on Jesse's
computer) in step (5) and then another commit (again on Jesse's
computer) in step (6). 

Note that we don't actually need (5) to do tag-sharing. The only reason
it's there is for keeping history.

I'm pretty sure that we don't need a commit on David's computer in step
(1), because what the history would record is when the tag-sharing
utility changed your tags, not when you did.

Note also that all we would really be asking git to do here is keep an
ordered collection of diffs of a single file. Honest question: since
this is the barest possible form of version control, is git necessary?
Some of the features, like commit messages, don't seem to fit well with
this model; and others, like branching, seem pretty useless. What's the
value added over just keeping a (compressed?) collection of diffs for
each namespace?

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

Re: tag sharing

[Jesse Rosenthal]

On Fri, 07 Oct 2011 07:36:30 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote:
 What's the value added over just keeping a (compressed?) collection of
 diffs for each namespace?

Okay -- please don't bother answering this part. It was early in the
morning, and I forgot some of the obvious advantages of real version
control (we can roll back to a previous moment, etc). We still don't
need most of what git offers, but if it's the best tool for keeping
track of the move from the file in step (5) to the file in step (6),
then sure, let's use it.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

tag sharing

[Jesse Rosenthal]

On Thu, 06 Oct 2011 17:23:21 -0300, David Bremner  wrote:
> What doesn't work is searches for the whole namespace "notmuch search
> tag:bremner.*" will return nothing, even though "notmuch search
> tag:bremner.to-fix" does.

A simple shell way to do this would be

notmuch search-tags | grep "^bremner\." | xargs -I {} notmuch search tag:{}

That's pretty quick over a fair amount of messages. It would be quicker,
I imagine, if it did the grepping inside of a program, but this is still
way down there in the subsecond range.

NB. I don't have that many tags, so maybe the grepping step would bog
down a bit if I had more. But I doubt someone would have that much more
than a few hundred.

tag sharing

[Jesse Rosenthal]

On Thu, 06 Oct 2011 11:18:51 -0300, David Bremner  wrote:
> something like that sounds plausible. Currently the query parser doesn't
> handle searches like "tag:bremner/to-fix" very well, because it
> helpfully splits at '/' (aiui; maybe somebody else can explain it
> better).  "notmuch search "tag:notmuch*" does not seem to work either,
> so my first idea to kludge around the problem by using
> e.g. "notmuchPushed" doesn't seem to work either.

A period works: `tag:bremner.to-fix`. That would fit with java/python
conventions. Double-colons also seem to work, for what it's worth:
`tag:bremner::to-fix`

tag sharing

[Jesse Rosenthal]

On Thu, 06 Oct 2011 09:56:43 -0300, David Bremner  wrote:
> Jesse, do you remember why you decided to roll your own?

Only reason I can remember (a year and a half later) of is that it
seemed like the basic illustration of concept would be a saturday
morning's project. In retrospect, I think the main issue was that I was
trying to figure out how history would be kept. By using git, though,
your idea would be that we get history for free, right?

I think my format was:

 
12345  foo at barto-fix
13456  bar at foofeature-request

But using git would get us timestamps for free too, I guess.  And if we
get rid of timestamps, then we just have dumps. So what we would really
just need is a thin namespacing layer in some scripting language on top
of git? I.e., all we need something to just keep different dumps in
different namespaces, so that when I pull your dump, the tags come in as
`bremner/to-fix` (or whatever our separator is), and then when I dump
all `bremner` tags, it removes the namespace and puts it in
`bremner.tagfile`.

One rather obvious thing that I discovered: processing dumps and
restores from the ui is pretty slow, because you have to output a huge
file, and then find the tags in your preferred namespace. So using
either the library or the bindings would probably speed things up quite
a bit, by only dumping the tags you care about. Which means it couldn't
just be a shell script: it would have to be c/ruby/python.

Best,
Jesse

Re: tag sharing

[Jesse Rosenthal]

On Thu, 06 Oct 2011 09:56:43 -0300, David Bremner da...@tethera.net wrote:
 Jesse, do you remember why you decided to roll your own?

Only reason I can remember (a year and a half later) of is that it
seemed like the basic illustration of concept would be a saturday
morning's project. In retrospect, I think the main issue was that I was
trying to figure out how history would be kept. By using git, though,
your idea would be that we get history for free, right?

I think my format was:

TIMESTAMPMESSAGID TAG
12345  foo@barto-fix
13456  bar@foofeature-request

But using git would get us timestamps for free too, I guess.  And if we
get rid of timestamps, then we just have dumps. So what we would really
just need is a thin namespacing layer in some scripting language on top
of git? I.e., all we need something to just keep different dumps in
different namespaces, so that when I pull your dump, the tags come in as
`bremner/to-fix` (or whatever our separator is), and then when I dump
all `bremner` tags, it removes the namespace and puts it in
`bremner.tagfile`.

One rather obvious thing that I discovered: processing dumps and
restores from the ui is pretty slow, because you have to output a huge
file, and then find the tags in your preferred namespace. So using
either the library or the bindings would probably speed things up quite
a bit, by only dumping the tags you care about. Which means it couldn't
just be a shell script: it would have to be c/ruby/python.

Best,
Jesse


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

Re: tag sharing

[Jesse Rosenthal]

On Thu, 06 Oct 2011 11:18:51 -0300, David Bremner da...@tethera.net wrote:
 something like that sounds plausible. Currently the query parser doesn't
 handle searches like tag:bremner/to-fix very well, because it
 helpfully splits at '/' (aiui; maybe somebody else can explain it
 better).  notmuch search tag:notmuch* does not seem to work either,
 so my first idea to kludge around the problem by using
 e.g. notmuchPushed doesn't seem to work either.

A period works: `tag:bremner.to-fix`. That would fit with java/python
conventions. Double-colons also seem to work, for what it's worth:
`tag:bremner::to-fix`
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: tag sharing

[Jesse Rosenthal]

On Thu, 06 Oct 2011 17:23:21 -0300, David Bremner da...@tethera.net wrote:
 What doesn't work is searches for the whole namespace notmuch search
 tag:bremner.* will return nothing, even though notmuch search
 tag:bremner.to-fix does.

A simple shell way to do this would be

notmuch search-tags | grep ^bremner\. | xargs -I {} notmuch search tag:{}

That's pretty quick over a fair amount of messages. It would be quicker,
I imagine, if it did the grepping inside of a program, but this is still
way down there in the subsecond range.

NB. I don't have that many tags, so maybe the grepping step would bog
down a bit if I had more. But I doubt someone would have that much more
than a few hundred.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

tag sharing [was: Re: release-candidate/0.6 redux]

[Jesse Rosenthal]

On Wed, 08 Jun 2011 10:46:57 -0700, Jameson Graef Rollins  wrote:
> Did you guys try to address the issue of tag removal at all?  I've been
> trying to decide if this is something we need to worry about or not.
> For instance, if cworth pushed a tag ".needs-review", you would probably
> want to have that tag removed if cworth removed it.  I guess
> alternatively he could just push the tag ".reviewed" to nullify the
> meaning of the previous one.  I'm not sure that would work in all cases,
> though.

Yes, if he deletes the tag "public.needs-review" in his notmuch, and
then pushes it, it will delete the tag "cworth.needs-review" from yours.

A couple points about this:

1. If you added your own "needs-review" tag to things that have a
"cworth.needs-review" tag, that wouldn't be deleted. In other words,
cworth's actions will only affect that namespace. Now, if you delete it,
and push it, and Carl pulls back from you (meaning he trusts you), then
it would be deleted on his. When he pushes next, it will be deleted on
everyone who pulls from him.

I'm sure there are resolution paradoxes here. It only had a ten-minute
trial run one day on IRC with me and someone else.

2. The history is available. If you run `nm-remote history msg-id`, it
will show you its history of being added and deleted. I think it will
show by whom it was added or deleted as well, but I don't quite remember
(I hacked this up over a year ago).

Re: tag sharing [was: Re: release-candidate/0.6 redux]

[Jesse Rosenthal]

On Wed, 08 Jun 2011 10:46:57 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 Did you guys try to address the issue of tag removal at all?  I've been
 trying to decide if this is something we need to worry about or not.
 For instance, if cworth pushed a tag .needs-review, you would probably
 want to have that tag removed if cworth removed it.  I guess
 alternatively he could just push the tag .reviewed to nullify the
 meaning of the previous one.  I'm not sure that would work in all cases,
 though.

Yes, if he deletes the tag public.needs-review in his notmuch, and
then pushes it, it will delete the tag cworth.needs-review from yours.

A couple points about this:

1. If you added your own needs-review tag to things that have a
cworth.needs-review tag, that wouldn't be deleted. In other words,
cworth's actions will only affect that namespace. Now, if you delete it,
and push it, and Carl pulls back from you (meaning he trusts you), then
it would be deleted on his. When he pushes next, it will be deleted on
everyone who pulls from him.

I'm sure there are resolution paradoxes here. It only had a ten-minute
trial run one day on IRC with me and someone else.

2. The history is available. If you run `nm-remote history msg-id`, it
will show you its history of being added and deleted. I think it will
show by whom it was added or deleted as well, but I don't quite remember
(I hacked this up over a year ago).

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

tag sharing [was: Re: release-candidate/0.6 redux]

[Jesse Rosenthal]

On Mon, 06 Jun 2011 09:28:13 -0700, Jameson Graef Rollins  wrote:
> I've been thinking about this more and it really seems we need a way to
> just share tags.  What if we had a way to export all the tags for a set
> of messages as a notmuch dump file, that could just be piped into
> notmuch to modify tags?  This would be a great way for lots of people to
> keep tags synced on a set of messages.

After a conversation with David last year about bug-tracking, I worked
up a rough python-based prototype of this. It worked in terms of
namespaces, so Carl could associate the namespace "public" with a list
of tags he publishes to a http-accessable location. And you could
associate the namespace "cworth" with those same tags.

He types `whatevercommand push public` and all tags "public.*" go to an
config-associated URL.

You type `whatevercommand pull cworth` and the tags come down from that
URL as "cworth.*".

So what he has as "public.to-push" comes down to your notmuch as
"cworth.to-push".

It's available here:

http://commonmeasure.org/~jkr/git/nm-remote.git

See these emails for more (but note that the repo url has changed to the
above).

id:"m1k4rkkchy.fsf at watt.gilman.jhu.edu"
id:"m1hbmokbxj.fsf at watt.gilman.jhu.edu"

There were some details and inherent ambiguities about conflict
resolution, and the above emails explain how I dealt with them. 

Note also that it uses python's configparser, which will overwrite your
config -- which means it'll get rid of your comments. So if you use any
of the config-writing commands, make sure you back up your config first.

Best,
Jesse

Re: tag sharing [was: Re: release-candidate/0.6 redux]

[Jesse Rosenthal]

On Mon, 06 Jun 2011 09:28:13 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 I've been thinking about this more and it really seems we need a way to
 just share tags.  What if we had a way to export all the tags for a set
 of messages as a notmuch dump file, that could just be piped into
 notmuch to modify tags?  This would be a great way for lots of people to
 keep tags synced on a set of messages.

After a conversation with David last year about bug-tracking, I worked
up a rough python-based prototype of this. It worked in terms of
namespaces, so Carl could associate the namespace public with a list
of tags he publishes to a http-accessable location. And you could
associate the namespace cworth with those same tags.

He types `whatevercommand push public` and all tags public.* go to an
config-associated URL.

You type `whatevercommand pull cworth` and the tags come down from that
URL as cworth.*.

So what he has as public.to-push comes down to your notmuch as
cworth.to-push.

It's available here:

http://commonmeasure.org/~jkr/git/nm-remote.git

See these emails for more (but note that the repo url has changed to the
above).

id:m1k4rkkchy@watt.gilman.jhu.edu
id:m1hbmokbxj@watt.gilman.jhu.edu

There were some details and inherent ambiguities about conflict
resolution, and the above emails explain how I dealt with them. 

Note also that it uses python's configparser, which will overwrite your
config -- which means it'll get rid of your comments. So if you use any
of the config-writing commands, make sure you back up your config first.

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

Header and other questions

[Jesse Rosenthal]

Hi,

On Mon, 16 May 2011 17:15:17 +0200, Daniel Schoepe  wrote:
> I think this is only a subset of the requested functionality, since one
> can only tag consecutive threads at once.

It seems like for non-consecutive messages to be tagged, there'd have to
be some sort of mutt-style message-marking facility. There was some
discussion when the feature was first introduced about whether to go
with region or marking. I think I wrote a quick version of both. (I just
checked -- that uncertainty is actually still there in the commit msg of
4c9585933 where the region feature comes in.)

The decision, if I remember correctly, was that regions are so intuitive
for emacs users, and many people reported trying to tag by region
without thinking about it, that this approach would make sense for the
emacs interface. In other words, keep the emacs interface emacsy. I
think I still agree with that, since I feel like having both would be
confusing (what do you do when you select a marked-line in a region?)
and I like the one I tend toward intuitively. But I certainly see the
benefit of the other functionality as well.

Best,
Jesse

Header and other questions

[Jesse Rosenthal]

On Sun, 15 May 2011 23:56:11 +0200, Xavier Maillard  
wrote:
> On Sat, 14 May 2011 22:23:16 -0700, mueen at nawaz.org wrote:
> 
> > 3. Can I mark a bunch of messages for tagging in the Emacs interface? I
> > know I can tag all messages in a query, but sometimes I'd just like to
> > select a few manually and tag them (or apply some other command to
> > them).
> 
> I do not think that's possible at the moment but that could be quite
> useful.

It's possible, and works the way you'd think it would -- just select a
bunch of threads in the search list, and then tag them. It will apply
the tag to the messages in the region. (In fact, tagging a single thread
is just a special case of this, with a one-line region.)

--Jesse

Re: Header and other questions

[Jesse Rosenthal]

On Sun, 15 May 2011 23:56:11 +0200, Xavier Maillard xav...@maillard.im wrote:
 On Sat, 14 May 2011 22:23:16 -0700, mu...@nawaz.org wrote:
 
  3. Can I mark a bunch of messages for tagging in the Emacs interface? I
  know I can tag all messages in a query, but sometimes I'd just like to
  select a few manually and tag them (or apply some other command to
  them).
 
 I do not think that's possible at the moment but that could be quite
 useful.

It's possible, and works the way you'd think it would -- just select a
bunch of threads in the search list, and then tag them. It will apply
the tag to the messages in the region. (In fact, tagging a single thread
is just a special case of this, with a one-line region.)

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