Re: [PATCH 3/5] cli/count: add --lastmod

[Daniel Schoepe]

On Sat, 15 Aug 2015 12:42 +0200, David Bremner wrote:
 For me compaction is a rare event, so having to take the fallback path
 and do a full dump or whatever doesn't seem so bad. If you don't want to
 have a fallback path, then I guess you need to guarantee externally that
 no bad changes happen and either ignore the uuid's or copy them
 forward in your external tool.

 Mainly though I think this will be fixed in Xapian. As it happens Xapian
 developer Olly Betts is here at DebConf, and I discussed this problem
 with him. According to Olly, in-progress / future versions of compact
 will function in place, and guarantee the UUID is preserved. I'm not
 sure of the timeline here, but given our scarce developer resources, I
 think I'd rather wait for Olly to fix this.

Okay, I'm convinced now. The series looks good to me otherwise.

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

[PATCH 3/5] cli/count: add --lastmod

[Daniel Schoepe]

On Fri, 14 Aug 2015 18:47 +0200, David Bremner wrote:
> +``--lastmod``
> + Append lastmod (counter for number of database updates) and UUID
> + to the output. lastmod values are only comparable between databases
> + with the same UUID.

Sorry to keep harping on this, but I'm not entirely happy with the way
we handle notmuch-compact here (and in the other commit that mentions
compacting explicitly). Given that lastmod values (and pretty much
everything else) aren't affected by compacting, would it perhaps make
sense to copy the previous UUID to the newly compacted database?

Given that a compacted database is "indistinguishable" from the previous
non-compacted database, we may want to signal that it's still the "same
database". Is there a case where compacting actually makes a difference
to anything making use of lastmod values?

Best regards,
Daniel

Re: [PATCH 3/5] cli/count: add --lastmod

[Daniel Schoepe]

On Fri, 14 Aug 2015 18:47 +0200, David Bremner wrote:
 +``--lastmod``
 + Append lastmod (counter for number of database updates) and UUID
 + to the output. lastmod values are only comparable between databases
 + with the same UUID.

Sorry to keep harping on this, but I'm not entirely happy with the way
we handle notmuch-compact here (and in the other commit that mentions
compacting explicitly). Given that lastmod values (and pretty much
everything else) aren't affected by compacting, would it perhaps make
sense to copy the previous UUID to the newly compacted database?

Given that a compacted database is indistinguishable from the previous
non-compacted database, we may want to signal that it's still the same
database. Is there a case where compacting actually makes a difference
to anything making use of lastmod values?

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

[PATCH 3/5] cli/count: add --output=modifications

[Daniel Schoepe]

Maybe another consistent solution is to add a --format argument to
count, with JSON as one option. That way we could even add more
information to other count results (if that becomes needed at some
point) without breaking code using the JSON interface.

Best regards,
Daniel

Re: [PATCH 3/5] cli/count: add --output=modifications

[Daniel Schoepe]

Maybe another consistent solution is to add a --format argument to
count, with JSON as one option. That way we could even add more
information to other count results (if that becomes needed at some
point) without breaking code using the JSON interface.

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

[PATCH] test: Tests for combining --batch and --remove-all

[Daniel Schoepe]

This patch adds some tests for combining --remove-all with --batch or
--input when calling notmuch-tag.
---
 test/T150-tagging.sh | 25 +
 1 file changed, 25 insertions(+)

diff --git a/test/T150-tagging.sh b/test/T150-tagging.sh
index 821d393..8adcabc 100755
--- a/test/T150-tagging.sh
+++ b/test/T150-tagging.sh
@@ -38,6 +38,17 @@ test_expect_equal "$output" "\
 thread:XXX   2001-01-05 [1/1] Notmuch Test Suite; One ()
 thread:XXX   2001-01-05 [1/1] Notmuch Test Suite; Two (tag5 tag6 unread)"

+test_begin_subtest "Remove all with batch"
+notmuch tag +tag1 One
+notmuch tag --remove-all --batch < OUTPUT
 notmuch restore --format=batch-tag < backup.tags
 test_expect_equal_file batch.expected OUTPUT

+test_begin_subtest "--batch --input --remove-all"
+notmuch dump --format=batch-tag > backup.tags
+notmuch tag +foo +bar -- One
+notmuch tag +tag7 -- Two
+notmuch tag --batch --input=batch.in --remove-all
+notmuch search \* | notmuch_search_sanitize > OUTPUT
+notmuch restore --format=batch-tag < backup.tags
+cat > batch_removeall.expected < EXPECTED
 notmuch tag --batch <

Change test to use empty tag modifications

[Daniel Schoepe]

As Jani pointed out, having a test checking the functionality
with an empty line of tag modification makes more sense than
having two tests with non-empty tags, so here's a fixed version
of the preceding patch.

Best regards,
Daniel

[PATCH 2/2] test: Tests for combining --batch and --remove-all

[Daniel Schoepe]

This patch adds some tests for combining --remove-all with --batch or
--input when calling notmuch-tag.
---
 test/T150-tagging.sh | 24 
 1 file changed, 24 insertions(+)

diff --git a/test/T150-tagging.sh b/test/T150-tagging.sh
index 821d393..19539dd 100755
--- a/test/T150-tagging.sh
+++ b/test/T150-tagging.sh
@@ -38,6 +38,16 @@ test_expect_equal "$output" "\
 thread:XXX   2001-01-05 [1/1] Notmuch Test Suite; One ()
 thread:XXX   2001-01-05 [1/1] Notmuch Test Suite; Two (tag5 tag6 unread)"

+test_begin_subtest "Remove all with batch"
+notmuch tag --remove-all --batch < OUTPUT
 notmuch restore --format=batch-tag < backup.tags
 test_expect_equal_file batch.expected OUTPUT

+test_begin_subtest "--batch --input --remove-all"
+notmuch dump --format=batch-tag > backup.tags
+notmuch tag +foo +bar -- One
+notmuch tag +tag7 -- Two
+notmuch tag --batch --input=batch.in --remove-all
+notmuch search \* | notmuch_search_sanitize > OUTPUT
+notmuch restore --format=batch-tag < backup.tags
+cat > batch_removeall.expected < EXPECTED
 notmuch tag --batch <

[PATCH 1/2] cli: Allow combining --remove-all and --batch

[Daniel Schoepe]

This patch removes the restriction on notmuch-tag that disallows using
both --remove-all and --batch. Combining the two options removes tags
on all messages affected by each query before applying the new tags.
---
 notmuch-tag.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/notmuch-tag.c b/notmuch-tag.c
index 38d99aa..f1df986 100644
--- a/notmuch-tag.c
+++ b/notmuch-tag.c
@@ -231,10 +231,6 @@ notmuch_tag_command (notmuch_config_t *config, int argc, 
char *argv[])
fprintf (stderr, "Can't specify both cmdline and stdin!\n");
return EXIT_FAILURE;
}
-   if (remove_all) {
-   fprintf (stderr, "Can't specify both --remove-all and --batch\n");
-   return EXIT_FAILURE;
-   }
 } else {
tag_ops = tag_op_list_create (config);
if (tag_ops == NULL) {
-- 
2.5.0

[PATCH] notmuch-tag: Allow using both --remove-all and --batch

[Daniel Schoepe]

Hi,

I noticed that it makes sense to combine the --batch and --remove-all
options to notmuch. This can be used, for instance, when synchronizing
tags by transferring the tags for all changed mails.

This series removes this (undocumented) restriction and adds some
tests.

Best regards,
Daniel

[PATCH] notmuch-tag: Allow using both --remove-all and --batch

[Daniel Schoepe]

Hi,

I noticed that it makes sense to combine the --batch and --remove-all
options to notmuch. This can be used, for instance, when synchronizing
tags by transferring the tags for all changed mails.

This series removes this (undocumented) restriction and adds some
tests.

Best regards,
Daniel

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

[PATCH 2/2] test: Tests for combining --batch and --remove-all

[Daniel Schoepe]

This patch adds some tests for combining --remove-all with --batch or
--input when calling notmuch-tag.
---
 test/T150-tagging.sh | 24 
 1 file changed, 24 insertions(+)

diff --git a/test/T150-tagging.sh b/test/T150-tagging.sh
index 821d393..19539dd 100755
--- a/test/T150-tagging.sh
+++ b/test/T150-tagging.sh
@@ -38,6 +38,16 @@ test_expect_equal $output \
 thread:XXX   2001-01-05 [1/1] Notmuch Test Suite; One ()
 thread:XXX   2001-01-05 [1/1] Notmuch Test Suite; Two (tag5 tag6 unread)
 
+test_begin_subtest Remove all with batch
+notmuch tag --remove-all --batch EOF
++tag1 -- One
++tag3 +tag4 +inbox -- Two
+EOF
+output=$(notmuch search \* | notmuch_search_sanitize)
+test_expect_equal $output \
+thread:XXX   2001-01-05 [1/1] Notmuch Test Suite; One (tag1)
+thread:XXX   2001-01-05 [1/1] Notmuch Test Suite; Two (inbox tag3 tag4)
+
 test_begin_subtest Remove all with a no-op
 notmuch tag +inbox +tag1 +unread One
 notmuch tag --remove-all +foo +inbox +tag1 -foo +unread Two
@@ -102,6 +112,20 @@ notmuch search \* | notmuch_search_sanitize  OUTPUT
 notmuch restore --format=batch-tag  backup.tags
 test_expect_equal_file batch.expected OUTPUT
 
+test_begin_subtest --batch --input --remove-all
+notmuch dump --format=batch-tag  backup.tags
+notmuch tag +foo +bar -- One
+notmuch tag +tag7 -- Two
+notmuch tag --batch --input=batch.in --remove-all
+notmuch search \* | notmuch_search_sanitize  OUTPUT
+notmuch restore --format=batch-tag  backup.tags
+cat  batch_removeall.expected EOF
+thread:XXX   2001-01-05 [1/1] Notmuch Test Suite; One (@ tag6)
+thread:XXX   2001-01-05 [1/1] Notmuch Test Suite; Two (tag6)
+EOF
+test_expect_equal_file batch_removeall.expected OUTPUT
+rm batch_removeall.expected
+
 test_begin_subtest --batch, blank lines and comments
 notmuch dump | sort  EXPECTED
 notmuch tag --batch EOF
-- 
2.5.0

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

[PATCH 1/2] cli: Allow combining --remove-all and --batch

[Daniel Schoepe]

This patch removes the restriction on notmuch-tag that disallows using
both --remove-all and --batch. Combining the two options removes tags
on all messages affected by each query before applying the new tags.
---
 notmuch-tag.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/notmuch-tag.c b/notmuch-tag.c
index 38d99aa..f1df986 100644
--- a/notmuch-tag.c
+++ b/notmuch-tag.c
@@ -231,10 +231,6 @@ notmuch_tag_command (notmuch_config_t *config, int argc, 
char *argv[])
fprintf (stderr, Can't specify both cmdline and stdin!\n);
return EXIT_FAILURE;
}
-   if (remove_all) {
-   fprintf (stderr, Can't specify both --remove-all and --batch\n);
-   return EXIT_FAILURE;
-   }
 } else {
tag_ops = tag_op_list_create (config);
if (tag_ops == NULL) {
-- 
2.5.0

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

Change test to use empty tag modifications

[Daniel Schoepe]

As Jani pointed out, having a test checking the functionality
with an empty line of tag modification makes more sense than
having two tests with non-empty tags, so here's a fixed version
of the preceding patch.

Best regards,
Daniel

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

[PATCH] test: Tests for combining --batch and --remove-all

[Daniel Schoepe]

This patch adds some tests for combining --remove-all with --batch or
--input when calling notmuch-tag.
---
 test/T150-tagging.sh | 25 +
 1 file changed, 25 insertions(+)

diff --git a/test/T150-tagging.sh b/test/T150-tagging.sh
index 821d393..8adcabc 100755
--- a/test/T150-tagging.sh
+++ b/test/T150-tagging.sh
@@ -38,6 +38,17 @@ test_expect_equal $output \
 thread:XXX   2001-01-05 [1/1] Notmuch Test Suite; One ()
 thread:XXX   2001-01-05 [1/1] Notmuch Test Suite; Two (tag5 tag6 unread)
 
+test_begin_subtest Remove all with batch
+notmuch tag +tag1 One
+notmuch tag --remove-all --batch EOF
+-- One
++tag3 +tag4 +inbox -- Two
+EOF
+output=$(notmuch search \* | notmuch_search_sanitize)
+test_expect_equal $output \
+thread:XXX   2001-01-05 [1/1] Notmuch Test Suite; One ()
+thread:XXX   2001-01-05 [1/1] Notmuch Test Suite; Two (inbox tag3 tag4)
+
 test_begin_subtest Remove all with a no-op
 notmuch tag +inbox +tag1 +unread One
 notmuch tag --remove-all +foo +inbox +tag1 -foo +unread Two
@@ -102,6 +113,20 @@ notmuch search \* | notmuch_search_sanitize  OUTPUT
 notmuch restore --format=batch-tag  backup.tags
 test_expect_equal_file batch.expected OUTPUT
 
+test_begin_subtest --batch --input --remove-all
+notmuch dump --format=batch-tag  backup.tags
+notmuch tag +foo +bar -- One
+notmuch tag +tag7 -- Two
+notmuch tag --batch --input=batch.in --remove-all
+notmuch search \* | notmuch_search_sanitize  OUTPUT
+notmuch restore --format=batch-tag  backup.tags
+cat  batch_removeall.expected EOF
+thread:XXX   2001-01-05 [1/1] Notmuch Test Suite; One (@ tag6)
+thread:XXX   2001-01-05 [1/1] Notmuch Test Suite; Two (tag6)
+EOF
+test_expect_equal_file batch_removeall.expected OUTPUT
+rm batch_removeall.expected
+
 test_begin_subtest --batch, blank lines and comments
 notmuch dump | sort  EXPECTED
 notmuch tag --batch EOF
-- 
2.5.0

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

[PATCH 4/5] cli: add global option "--uuid"

[Daniel Schoepe]

On Mon, 10 Aug 2015 13:32 +0200, David Bremner wrote:
> So compacting is in fact a bit of a strange case, it preserves the
> lastmod counters (because those are just terms on documents), but not
> the uuid. This means from notmuch point of view have no programmatic way
> to know that we can trust the lastmod data, i.e. no way to distinguish a
> previous notmuch-compact from "notmuch dump && rm the database &&
> notmuch new && notmuch restore".  On the other hand, I _think_ we could
> promise the user that lastmod data is preserved by compacting; they
> would just have to tell whatever external tool to ignore uuid errors and
> perhaps set the new uuid.

Yeah, I think it's reasonable to assume that if the user will delete and
recreate the database, they will also perform the necessary
reinitialization of whatever tool makes use of lastmod / UUID. I guess
this also means that tools often only care about lastmod values and not
the UUID, to allow for compacting without thinking the database is
completely different now.

Another option is to include lastmod values in the output of
notmuch-dump. Doing that in a clean way might be hard though and I think
this shouldn't be part of this series (which looks fine to me now).

Best regards,
Daniel

[PATCH 4/5] cli: add global option "--uuid"

[Daniel Schoepe]

On Sun, 09 Aug 2015 11:24+0200, David Bremner wrote:
> +``--uuid=HEX``
> +   Enforce that the database UUID (a unique identifier which
> +   persists until e.g. the database is compacted)
> +   is HEX; exit with an error if it is not. This is useful to
> +   detect rollover in modification counts on messages. You can
> +   find this UUID in the first column of output from
> +   ``notmuch count --output=modifications``

I think it's not entirely clear what the connection between the UUID and
the revisions on messages is. For example, compacting a database
shouldn't make a difference "extensionally", so the naive assumption
might be that the UUID, or, maybe more importantly, the revision counts
don't change.

For example, if lastmod queries are used to incrementally back up or
synchronize tags, then it doesn't matter if the database got compacted,
all one cares about are the changes to messages' tags since an earlier
point.

Based on quick experiments, it seems that the revisions don't change
when compacting the database; is this something that the patches
guarantee or a coincidence?

Best regards,
Daniel

Re: [PATCH 4/5] cli: add global option --uuid

[Daniel Schoepe]

On Mon, 10 Aug 2015 13:32 +0200, David Bremner wrote:
 So compacting is in fact a bit of a strange case, it preserves the
 lastmod counters (because those are just terms on documents), but not
 the uuid. This means from notmuch point of view have no programmatic way
 to know that we can trust the lastmod data, i.e. no way to distinguish a
 previous notmuch-compact from notmuch dump  rm the database 
 notmuch new  notmuch restore.  On the other hand, I _think_ we could
 promise the user that lastmod data is preserved by compacting; they
 would just have to tell whatever external tool to ignore uuid errors and
 perhaps set the new uuid.

Yeah, I think it's reasonable to assume that if the user will delete and
recreate the database, they will also perform the necessary
reinitialization of whatever tool makes use of lastmod / UUID. I guess
this also means that tools often only care about lastmod values and not
the UUID, to allow for compacting without thinking the database is
completely different now.

Another option is to include lastmod values in the output of
notmuch-dump. Doing that in a clean way might be hard though and I think
this shouldn't be part of this series (which looks fine to me now).

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

Re: [PATCH 4/5] cli: add global option --uuid

[Daniel Schoepe]

On Sun, 09 Aug 2015 11:24+0200, David Bremner wrote:
 +``--uuid=HEX``
 +   Enforce that the database UUID (a unique identifier which
 +   persists until e.g. the database is compacted)
 +   is HEX; exit with an error if it is not. This is useful to
 +   detect rollover in modification counts on messages. You can
 +   find this UUID in the first column of output from
 +   ``notmuch count --output=modifications``

I think it's not entirely clear what the connection between the UUID and
the revisions on messages is. For example, compacting a database
shouldn't make a difference extensionally, so the naive assumption
might be that the UUID, or, maybe more importantly, the revision counts
don't change.

For example, if lastmod queries are used to incrementally back up or
synchronize tags, then it doesn't matter if the database got compacted,
all one cares about are the changes to messages' tags since an earlier
point.

Based on quick experiments, it seems that the revisions don't change
when compacting the database; is this something that the patches
guarantee or a coincidence?

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

[PATCH 6/6] lib: Add "lastmod:" queries for filtering by last modification

[Daniel Schoepe]

On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote:
> +The **lastmod:** prefix can be used to restrict the result by the
> +database revision number of when messages were last modified (tags
> +were added/removed or filenames changed).  This is usually used in
> +conjunction with the **--db-revision** argument to **notmuch search**
> +to find messages that have changed since an earlier query.

It might be helpful to describe why --db-revision is needed here. At
first glance, just using `notmuch search lastmod:UUID..' looks good
enough to get all changed messages since UUID. Indeed, it's not entirely
clear to me under what conditions just using this query causes problems.
Moreover, it would be quite nice and intuitive if that query did the job
without having to constrain the database revision manually as well.

Best regards,
Daniel

[PATCH 5/6] cli: add global option "--db-revision"

[Daniel Schoepe]

On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote:
> +``--db-revision=UUID``
> +   Enforce that the database revision is UUID. This is useful to
> +   detect rollover in modification counts on messages. You can
> +   find this UUID in the first column of output from
> +   ``notmuch count --output=modifications``

I'm not sure if the wording here is entirely clear. When reading this
the first time, to me it sounded like it might give you a view of the
database from when the revision was UUID. Maybe we can clarify here that
this will result in notmuch exiting if the revision is not matched.

Best regards,
Daniel

[PATCH 2/6] lib: Add per-message last modification tracking

[Daniel Schoepe]

Hi,

On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote:
> + /* Prior to NOTMUCH_FEATURE_LAST_MOD, messages did not
> +  * track modification revisions.  Give all messages a
> +  * revision of 1.
> +  */
> + if (new_features & NOTMUCH_FEATURE_LAST_MOD)
> + _notmuch_message_upgrade_last_mod (message);
> [..]
> +/* Upgrade a message to support NOTMUCH_FEATURE_LAST_MOD.  The caller
> + * must call _notmuch_message_sync. */
> +void
> +_notmuch_message_upgrade_last_mod (notmuch_message_t *message)
> +{
> +/* _notmuch_message_sync will update the last modification
> + * revision; we just have to ask it to. */
> +message->modified = TRUE;
> +}
> +

The comment in the first part says that message without LAST_MOD get a
revision of 1, but as far as I can tell, _notmuch_message_sync will
actually put the next revision number on the message. If this is what's
happening, either the comment or the behavior should be changed,
depending on what's intended.

Best regards,
Daniel

Re: [PATCH 5/6] cli: add global option --db-revision

[Daniel Schoepe]

On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote:
 +``--db-revision=UUID``
 +   Enforce that the database revision is UUID. This is useful to
 +   detect rollover in modification counts on messages. You can
 +   find this UUID in the first column of output from
 +   ``notmuch count --output=modifications``

I'm not sure if the wording here is entirely clear. When reading this
the first time, to me it sounded like it might give you a view of the
database from when the revision was UUID. Maybe we can clarify here that
this will result in notmuch exiting if the revision is not matched.

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

Re: [PATCH 6/6] lib: Add lastmod: queries for filtering by last modification

[Daniel Schoepe]

On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote:
 +The **lastmod:** prefix can be used to restrict the result by the
 +database revision number of when messages were last modified (tags
 +were added/removed or filenames changed).  This is usually used in
 +conjunction with the **--db-revision** argument to **notmuch search**
 +to find messages that have changed since an earlier query.

It might be helpful to describe why --db-revision is needed here. At
first glance, just using `notmuch search lastmod:UUID..' looks good
enough to get all changed messages since UUID. Indeed, it's not entirely
clear to me under what conditions just using this query causes problems.
Moreover, it would be quite nice and intuitive if that query did the job
without having to constrain the database revision manually as well.

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

Re: [PATCH 2/6] lib: Add per-message last modification tracking

[Daniel Schoepe]

Hi,

On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote:
 + /* Prior to NOTMUCH_FEATURE_LAST_MOD, messages did not
 +  * track modification revisions.  Give all messages a
 +  * revision of 1.
 +  */
 + if (new_features  NOTMUCH_FEATURE_LAST_MOD)
 + _notmuch_message_upgrade_last_mod (message);
 [..]
 +/* Upgrade a message to support NOTMUCH_FEATURE_LAST_MOD.  The caller
 + * must call _notmuch_message_sync. */
 +void
 +_notmuch_message_upgrade_last_mod (notmuch_message_t *message)
 +{
 +/* _notmuch_message_sync will update the last modification
 + * revision; we just have to ask it to. */
 +message-modified = TRUE;
 +}
 +

The comment in the first part says that message without LAST_MOD get a
revision of 1, but as far as I can tell, _notmuch_message_sync will
actually put the next revision number on the message. If this is what's
happening, either the comment or the behavior should be changed,
depending on what's intended.

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

notmuch-lazysync -- synchronizing tags using dropbox

[Daniel Schoepe]

Hi,

I needed a way to synchronize notmuch tags between machines without
having to sync all my mail as well (à la muchsync) and without using
Gmail labels for this. As a result, I ended up writing a small tool to
do this by using normal file synchronizers like seafile[1] or dropbox to
do the actual synchronization (since I was too lazy to (re)implement
this).

Since it's impractical to have the entire notmuch database synchronized
through dropbox, the tool uses a small sqlite database to record tag
commands performed on one machine and replay them on the others. This
works well if mail sorting is done on each machine separately and only
tag modifications performed in the frontend need to be recorded. The way
tag changes are logged is a bit of a hack, but it could be improved in
the future by adding a post-tag hook to notmuch.

More information can be found on github:

https://github.com/dschoepe/notmuch-lazysync

I hope someone else finds this useful as well.

Best regards,
Daniel

[1] https://www.seafile.com/en/home/
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] Fix documentation for notmuch--tag-hook functions

[Daniel Schoepe]

The second argument to notmuch-tag is now called tag-changes, but the
documentation for notmuch-before-tag-hook and notmuch-after-tag-hook
still used the old argument name `tags'. This resulted in broken hooks
when following the documentation.
---
 emacs/notmuch-tag.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-tag.el b/emacs/notmuch-tag.el
index f54aa9d..c7f62c9 100644
--- a/emacs/notmuch-tag.el
+++ b/emacs/notmuch-tag.el
@@ -265,7 +265,7 @@ changed (the normal case) are shown using formats from
 (defcustom notmuch-before-tag-hook nil
   "Hooks that are run before tags of a message are modified.

-'tags' will contain the tags that are about to be added or removed as
+'tag-changes' will contain the tags that are about to be added or removed as
 a list of strings of the form \"+TAG\" or \"-TAG\".
 'query' will be a string containing the search query that determines
 the messages that are about to be tagged"
@@ -277,7 +277,7 @@ the messages that are about to be tagged"
 (defcustom notmuch-after-tag-hook nil
   "Hooks that are run after tags of a message are modified.

-'tags' will contain the tags that were added or removed as
+'tag-changes' will contain the tags that were added or removed as
 a list of strings of the form \"+TAG\" or \"-TAG\".
 'query' will be a string containing the search query that determines
 the messages that were tagged"
-- 
2.4.3

post-tag hook?

[Daniel Schoepe]

Hi,

for what it's worth, you can simulate a post-tag hook in a somewhat ugly
way by putting a script called "notmuch" in front of the notmuch binary
in your PATH. The script can then call the original notmuch binary as
usual, inspect the first argument, and, if it's "tag", invoke your
script afterwards. I.e. something like this:

-
#!/bin/sh

/usr/bin/notmuch $@
retval=$?
if [[ "$1" == "tag" ]]; then
   shift 1
   your-script $@
fi
exit $retval
-

On a more general note, I'm experimenting with a way to synchronize tags
by logging and replaying tag commands performed on other machines and
for such an approach a post-tag hook would help. It seems to me that not
all use cases for a post-tag hook can be handled as nicely with mtimes.

Best regards,
Daniel

Re: post-tag hook?

[Daniel Schoepe]

Hi,

for what it's worth, you can simulate a post-tag hook in a somewhat ugly
way by putting a script called notmuch in front of the notmuch binary
in your PATH. The script can then call the original notmuch binary as
usual, inspect the first argument, and, if it's tag, invoke your
script afterwards. I.e. something like this:

-
#!/bin/sh

/usr/bin/notmuch $@
retval=$?
if [[ $1 == tag ]]; then
   shift 1
   your-script $@
fi
exit $retval
-

On a more general note, I'm experimenting with a way to synchronize tags
by logging and replaying tag commands performed on other machines and
for such an approach a post-tag hook would help. It seems to me that not
all use cases for a post-tag hook can be handled as nicely with mtimes.

Best regards,
Daniel

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

Snoozing messages

[Daniel Schoepe]

Hi Trevor,

yeah I saw that your client implemented that, but didn't want to switch
away from the standard emacs interface. Moreover, by using a daemon like
at the functionality can basically be used with any notmuch interface.

Best regards,
Daniel

On Thu, 06 Nov 2014 20:09 +0100, Trevor Jim wrote:
> BTW my nevermore client for notmuch implements snoozing in elisp. It's barely 
> functional but nice in that it does not rely on a separate daemon like at.
> https://github.com/tjim/nevermore
>
> -Trevor
> ?

Snoozing messages

[Daniel Schoepe]

Hi,

inspired by my alarm clock and the snooze feature found in some other
mail clients, I cobbled something together that allows snoozing
(i.e. removing a message from the inbox and adding it again later)
messages in notmuch. It's a small script that removes the inbox tag from
messages and schedules a job to add it again later using the at daemon
[1].

Time is specified in the format accepted by the perl library Date::Manip
[2]. It supports both absolute dates as well as relative times such as
"+5min".

The code is available here: https://github.com/dschoepe/notmuch-snooze

Best regards,
Daniel

[1] https://packages.qa.debian.org/a/at.html
[2] http://search.cpan.org/~sbeck/Date-Manip/lib/Date/Manip.pod
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 

Snoozing messages

[Daniel Schoepe]

Hi,

inspired by my alarm clock and the snooze feature found in some other
mail clients, I cobbled something together that allows snoozing
(i.e. removing a message from the inbox and adding it again later)
messages in notmuch. It's a small script that removes the inbox tag from
messages and schedules a job to add it again later using the at daemon
[1].

Time is specified in the format accepted by the perl library Date::Manip
[2]. It supports both absolute dates as well as relative times such as
+5min.

The code is available here: https://github.com/dschoepe/notmuch-snooze

Best regards,
Daniel

[1] https://packages.qa.debian.org/a/at.html
[2] http://search.cpan.org/~sbeck/Date-Manip/lib/Date/Manip.pod


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

Re: Snoozing messages

[Daniel Schoepe]

Hi Trevor,

yeah I saw that your client implemented that, but didn't want to switch
away from the standard emacs interface. Moreover, by using a daemon like
at the functionality can basically be used with any notmuch interface.

Best regards,
Daniel

On Thu, 06 Nov 2014 20:09 +0100, Trevor Jim wrote:
 BTW my nevermore client for notmuch implements snoozing in elisp. It's barely 
 functional but nice in that it does not rely on a separate daemon like at.
 https://github.com/tjim/nevermore

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

Notmuch scripts (again), now with more usenet

[Daniel Schoepe]

On Sun, 15.07.2012 18:36, David Bremner wrote:
> Are there actual users (other than the author)?

I started using the slrn2maildir script yesterday, but none of the other
scripts. It's working fine so far.

Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: Notmuch scripts (again), now with more usenet

[Daniel Schoepe]

On Sun, 15.07.2012 18:36, David Bremner wrote:
 Are there actual users (other than the author)?

I started using the slrn2maildir script yesterday, but none of the other
scripts. It's working fine so far.

Cheers,
Daniel


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

[PATCH] emacs: Add configurable wrapping width for notmuch-wash-wrap-long-lines

[Daniel Schoepe]

On Thu, 28.06.2012 09:41, Albin Stjerna wrote:
> If it didn't make it: what is now the preferred method of wrapping
> long lines when reading emails using notmuch/Emacs?

As far as I can tell, it didn't make it into mainline (yet?). However, it
changes a file that is rarely modified by other patches, so it should
still apply cleanly. At least it still did a few weeks ago.

Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: [PATCH] emacs: Add configurable wrapping width for notmuch-wash-wrap-long-lines

[Daniel Schoepe]

On Thu, 28.06.2012 09:41, Albin Stjerna wrote:
 If it didn't make it: what is now the preferred method of wrapping
 long lines when reading emails using notmuch/Emacs?

As far as I can tell, it didn't make it into mainline (yet?). However, it
changes a file that is rarely modified by other patches, so it should
still apply cleanly. At least it still did a few weeks ago.

Cheers,
Daniel


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

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

[Daniel Schoepe]

On Wed, 27.06.2012 19:55, Jameson Graef Rollins wrote:
> I actually rebound these keys immediately after the release, so I'm
> perfectly happy to change back.

Same here.

I think the ratio of cases where I wanted to reply to all
participants instead compared to just to the sender is something like
10:1.

Moreover, it's significantly easier to just remove recipients from the
headers than adding them, since one may no longer know who they are
after pressing reply, for example in big threads on mailing lists.

So these are my bikeshedding arguments for this change, but the last
point is not _that_ subjective, I hope.

Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

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

[Daniel Schoepe]

On Wed, 27.06.2012 19:55, Jameson Graef Rollins wrote:
 I actually rebound these keys immediately after the release, so I'm
 perfectly happy to change back.

Same here.

I think the ratio of cases where I wanted to reply to all
participants instead compared to just to the sender is something like
10:1.

Moreover, it's significantly easier to just remove recipients from the
headers than adding them, since one may no longer know who they are
after pressing reply, for example in big threads on mailing lists.

So these are my bikeshedding arguments for this change, but the last
point is not _that_ subjective, I hope.

Cheers,
Daniel


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

[PATCH v4 0/4] Allow JSON to use non-entire thread, and use for elide

[Daniel Schoepe]

On Tue, 24.04.2012 11:11, Mark Walters wrote:
> The first three patches implement the client side changes: one to
> allow null messages to be output in Json (without upsetting the
> parsing/structure), one to do the command line parsing for
> --entire-thread=false and one to update the schemata.
>
> The final emacs patch is independent (and the first three make sense
> without it) and uses this new functionality to implement the elide
> option.
>
> I think this addresses all review comments

LGTM (all four patches). I think both version of the command line
parsing patch would be acceptable, but the second one seems cleaner to
me.

Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: [PATCH v4 0/4] Allow JSON to use non-entire thread, and use for elide

[Daniel Schoepe]

On Tue, 24.04.2012 11:11, Mark Walters wrote:
 The first three patches implement the client side changes: one to
 allow null messages to be output in Json (without upsetting the
 parsing/structure), one to do the command line parsing for
 --entire-thread=false and one to update the schemata.

 The final emacs patch is independent (and the first three make sense
 without it) and uses this new functionality to implement the elide
 option.

 I think this addresses all review comments

LGTM (all four patches). I think both version of the command line
parsing patch would be acceptable, but the second one seems cleaner to
me.

Cheers,
Daniel


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

[PATCH] emacs: Add configurable wrapping width for notmuch-wash-wrap-long-lines

[Daniel Schoepe]

Hi Adam,

On Wed, 18.04.2012 17:30, Adam Wolfe Gordon wrote:
>> +(defvar notmuch-wash-wrap-lines-length nil
>> + ?"Wrap line after at most this many characters.
>> +
>> +If this is nil, lines in messages will be wrapped to fit in the
>> +current window. If this is a number, lines will be wrapped after
>> +this many characters or at the window width (whichever one is
>> +lower).")
>
> This should probably be a defcustom, in the notmuch-show section.

the reason for not making this a defcustom was that all of the other
functions in notmuch-wash.el use defvar for customization too, so
perhaps they should all be defcustom'd in a separate patch?

Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: [PATCH] emacs: Add configurable wrapping width for notmuch-wash-wrap-long-lines

[Daniel Schoepe]

Hi Adam,

On Wed, 18.04.2012 17:30, Adam Wolfe Gordon wrote:
 +(defvar notmuch-wash-wrap-lines-length nil
 +  Wrap line after at most this many characters.
 +
 +If this is nil, lines in messages will be wrapped to fit in the
 +current window. If this is a number, lines will be wrapped after
 +this many characters or at the window width (whichever one is
 +lower).)

 This should probably be a defcustom, in the notmuch-show section.

the reason for not making this a defcustom was that all of the other
functions in notmuch-wash.el use defvar for customization too, so
perhaps they should all be defcustom'd in a separate patch?

Cheers,
Daniel


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

[PATCH v10 1/2] emacs: User-defined sections in notmuch-hello

[Daniel Schoepe]

On Wed, 07 Mar 2012 20:53:48 +0100, Pieter Praet  wrote:
> On Thu, 01 Mar 2012 08:36:33 -0400, David Bremner  
> wrote:
> > 
> > Pushed, finally. Thanks for both of your hard work on this.
> >
> 
> 625 lines changed (425 added, 200 removed), in a *single* commit ?
> 
> It's a useful bit of functionality which definitely deserves to be
> included, and I do recognize and appreciate all the hard work that
> went into it, but... am I the only one who was a bit surprised to
> see this patch being applied [1] as-is?

I think it is hard to split this patch up into meaningful smaller
pieces, since it mainly moves parts from notmuch-hello into separate
functions and adds some defcustoms. So, the main opportunities for
splitting would be to do this moving of code into functions one function
per commit and to put the defcustoms and their quite lengthy
documentation in a separate commit (which would leave you with an
intermediate version that's seriously lacking in documentation).

I'm not sure if those two things are that useful, but if there's
consensus that the patch shouldn't stay in the way it is, I can give it
a shot (although it'd be a lot of tedious work).

Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: [PATCH v10 1/2] emacs: User-defined sections in notmuch-hello

[Daniel Schoepe]

On Wed, 07 Mar 2012 20:53:48 +0100, Pieter Praet pie...@praet.org wrote:
 On Thu, 01 Mar 2012 08:36:33 -0400, David Bremner da...@tethera.net wrote:
  
  Pushed, finally. Thanks for both of your hard work on this.
 
 
 625 lines changed (425 added, 200 removed), in a *single* commit ?
 
 It's a useful bit of functionality which definitely deserves to be
 included, and I do recognize and appreciate all the hard work that
 went into it, but... am I the only one who was a bit surprised to
 see this patch being applied [1] as-is?

I think it is hard to split this patch up into meaningful smaller
pieces, since it mainly moves parts from notmuch-hello into separate
functions and adds some defcustoms. So, the main opportunities for
splitting would be to do this moving of code into functions one function
per commit and to put the defcustoms and their quite lengthy
documentation in a separate commit (which would leave you with an
intermediate version that's seriously lacking in documentation).

I'm not sure if those two things are that useful, but if there's
consensus that the patch shouldn't stay in the way it is, I can give it
a shot (although it'd be a lot of tedious work).

Cheers,
Daniel


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

[PATCH v2] emacs: Pass a copy to notmuch-saved-search-sort-function

[Daniel Schoepe]

On Mar 5, 2012 5:43 PM, "Dmitry Kurochkin" 
> I do not buy the argument that we should help users who implement their
> own sorting functions but do not read documentation for functions they
> use.  Apparently, those who implemented the `sort' function had similar
> ideas.  And I do not think it is our job to add workarounds for it.

Yeah that also sounds a bit more consistent, I guess my perception was
colored by my surprise at learning that sort has side effects in elisp. :)

On Mon, 5 Mar 2012 22:55:54 +0200, Jani Nikula  wrote:
> Providing the customization of the sort function is more powerful than the
> compare function. In the case of saved searches I can imagine people might
> want to partially use the original order while sort the rest (e.g.
> important ones first in predefined order, others sorted). In fact this also
> allows dropping out some elements. And renaming. And changing the queries...
> 
> (I had something like that in mind originally but then settled with just
> capitalizing the important ones to show them first.)

I have the same objections to only providing a customization option for
comparing.

Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH v2] emacs: Pass a copy to notmuch-saved-search-sort-function

[Daniel Schoepe]

On Mon, 05 Mar 2012 06:21:52 +0400, Dmitry Kurochkin  wrote:
> On Thu,  1 Mar 2012 21:24:38 +0100, Daniel Schoepe  
> wrote:
> > notmuch-saved-search-sort-function might destructively modify its
> > input (`sort' does that, for instance), so it should not be given
> > notmuch-saved-searches directly.
> > ---
> 
> -1
> 
> I think we should require `notmuch-saved-search-sort-function' not to
> have side effects.  Current documentation should be more clear about
> this.  We need to fix `notmuch-sort-saved-searches' to copy the list
> before calling `sort'.  But we should not do it in
> `notmuch-hello-insert-saved-searches' for any sorting function (which
> may not need this copying).

My reasoning was that since sort is such a common function, many users
will probably use sort for their own sorting functions, not realizing
that it has side effects. This will lead to confusing behavior that's
not so easy to track down.

Copying the list of saved searches when running notmuch-hello does not
seem be relevant to performance to me, since it's a) not called that
often and b) the list of saved searches will rarely exceed 30 elements.

Hence, this way we can avoid some headaches for users who define their
own sorting functions at a negligible (performance) cost. Incidentally,
this is also how notmuch-hello did it before the user-defined sections
patches.

Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120305/96dfbe90/attachment.pgp>

Re: [PATCH v2] emacs: Pass a copy to notmuch-saved-search-sort-function

[Daniel Schoepe]

On Mon, 05 Mar 2012 06:21:52 +0400, Dmitry Kurochkin 
dmitry.kuroch...@gmail.com wrote:
 On Thu,  1 Mar 2012 21:24:38 +0100, Daniel Schoepe dan...@schoepe.org wrote:
  notmuch-saved-search-sort-function might destructively modify its
  input (`sort' does that, for instance), so it should not be given
  notmuch-saved-searches directly.
  ---
 
 -1
 
 I think we should require `notmuch-saved-search-sort-function' not to
 have side effects.  Current documentation should be more clear about
 this.  We need to fix `notmuch-sort-saved-searches' to copy the list
 before calling `sort'.  But we should not do it in
 `notmuch-hello-insert-saved-searches' for any sorting function (which
 may not need this copying).

My reasoning was that since sort is such a common function, many users
will probably use sort for their own sorting functions, not realizing
that it has side effects. This will lead to confusing behavior that's
not so easy to track down.

Copying the list of saved searches when running notmuch-hello does not
seem be relevant to performance to me, since it's a) not called that
often and b) the list of saved searches will rarely exceed 30 elements.

Hence, this way we can avoid some headaches for users who define their
own sorting functions at a negligible (performance) cost. Incidentally,
this is also how notmuch-hello did it before the user-defined sections
patches.

Cheers,
Daniel


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

Re: [PATCH v2] emacs: Pass a copy to notmuch-saved-search-sort-function

[Daniel Schoepe]

On Mar 5, 2012 5:43 PM, Dmitry Kurochkin dmitry.kuroch...@gmail.com
 I do not buy the argument that we should help users who implement their
 own sorting functions but do not read documentation for functions they
 use.  Apparently, those who implemented the `sort' function had similar
 ideas.  And I do not think it is our job to add workarounds for it.

Yeah that also sounds a bit more consistent, I guess my perception was
colored by my surprise at learning that sort has side effects in elisp. :)

On Mon, 5 Mar 2012 22:55:54 +0200, Jani Nikula j...@nikula.org wrote:
 Providing the customization of the sort function is more powerful than the
 compare function. In the case of saved searches I can imagine people might
 want to partially use the original order while sort the rest (e.g.
 important ones first in predefined order, others sorted). In fact this also
 allows dropping out some elements. And renaming. And changing the queries...
 
 (I had something like that in mind originally but then settled with just
 capitalizing the important ones to show them first.)

I have the same objections to only providing a customization option for
comparing.

Cheers,
Daniel


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

[PATCH] emacs-hello: Do not calculate the count of the messages in hidden sections

[Daniel Schoepe]

On Fri, 02 Mar 2012 01:34:03 +0100, Daniel Schoepe  
wrote:
> You can define other section that you can then hide, which was the main
> point of the original patch.

The defining other sections thing that is, not that you have more
things to hide.. :)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120302/94833da3/attachment.pgp>

[PATCH] emacs-hello: Do not calculate the count of the messages in hidden sections

[Daniel Schoepe]

On Thu, 01 Mar 2012 22:18:04 +, Mark Walters  
wrote:
> This looks fine to me and does speed things up when the "All tags"
> section is hidden (are there other sections I can hide?)

You can define other section that you can then hide, which was the main
point of the original patch.

Michal, your patch looks good to me too. Now that my two patches have
been pushed, I think this should go in as well.

Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH v2] emacs: Pass a copy to notmuch-saved-search-sort-function

[Daniel Schoepe]

notmuch-saved-search-sort-function might destructively modify its
input (`sort' does that, for instance), so it should not be given
notmuch-saved-searches directly.
---
 emacs/notmuch-hello.el |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index aad373d..e089290 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -575,7 +575,10 @@ Complete list of currently available key bindings:
   (let ((searches (notmuch-hello-query-counts
   (if notmuch-saved-search-sort-function
   (funcall notmuch-saved-search-sort-function
-   notmuch-saved-searches)
+   ;; Use a copy, since the sorting
+   ;; function may have side effects,
+   ;; e.g. if it just `sort's the input.
+   (copy-sequence notmuch-saved-searches))
 notmuch-saved-searches)
   :show-empty-searches notmuch-show-empty-saved-searches))
found-target-pos)
-- 
1.7.9.1

[PATCH v2 0/1] emacs: Pass a copy to notmuch-saved-search-sort-function

[Daniel Schoepe]

I overlooked that copy-seq is from cl.el. This version uses copy-sequence 
instead.

[PATCH] emacs: Pass a copy to notmuch-saved-search-sort-function

[Daniel Schoepe]

notmuch-saved-search-sort-function might destructively modify its
input (`sort' does that, for instance), so it should not be given
notmuch-saved-searches directly.
---
 emacs/notmuch-hello.el |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index aad373d..b2b22df 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -575,7 +575,10 @@ Complete list of currently available key bindings:
   (let ((searches (notmuch-hello-query-counts
   (if notmuch-saved-search-sort-function
   (funcall notmuch-saved-search-sort-function
-   notmuch-saved-searches)
+   ;; Use a copy, since the sorting
+   ;; function may have side effects,
+   ;; e.g. if it just `sort's the input.
+   (copy-seq notmuch-saved-searches))
 notmuch-saved-searches)
   :show-empty-searches notmuch-show-empty-saved-searches))
found-target-pos)
-- 
1.7.9.1

[PATCH 0/1] emacs: Pass a copy to notmuch-saved-search-sort-function

[Daniel Schoepe]

As Jani discovered, `sort' modifies its input list, leading to deleted
saved searches when using notmuch-sort-saved-searches.

[PATCH 0/1] emacs: Pass a copy to notmuch-saved-search-sort-function

[Daniel Schoepe]

As Jani discovered, `sort' modifies its input list, leading to deleted
saved searches when using notmuch-sort-saved-searches.

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

[PATCH] emacs: Pass a copy to notmuch-saved-search-sort-function

[Daniel Schoepe]

notmuch-saved-search-sort-function might destructively modify its
input (`sort' does that, for instance), so it should not be given
notmuch-saved-searches directly.
---
 emacs/notmuch-hello.el |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index aad373d..b2b22df 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -575,7 +575,10 @@ Complete list of currently available key bindings:
   (let ((searches (notmuch-hello-query-counts
   (if notmuch-saved-search-sort-function
   (funcall notmuch-saved-search-sort-function
-   notmuch-saved-searches)
+   ;; Use a copy, since the sorting
+   ;; function may have side effects,
+   ;; e.g. if it just `sort's the input.
+   (copy-seq notmuch-saved-searches))
 notmuch-saved-searches)
   :show-empty-searches notmuch-show-empty-saved-searches))
found-target-pos)
-- 
1.7.9.1

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

[PATCH v2 0/1] emacs: Pass a copy to notmuch-saved-search-sort-function

[Daniel Schoepe]

I overlooked that copy-seq is from cl.el. This version uses copy-sequence 
instead.

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

[PATCH v2] emacs: Pass a copy to notmuch-saved-search-sort-function

[Daniel Schoepe]

notmuch-saved-search-sort-function might destructively modify its
input (`sort' does that, for instance), so it should not be given
notmuch-saved-searches directly.
---
 emacs/notmuch-hello.el |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index aad373d..e089290 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -575,7 +575,10 @@ Complete list of currently available key bindings:
   (let ((searches (notmuch-hello-query-counts
   (if notmuch-saved-search-sort-function
   (funcall notmuch-saved-search-sort-function
-   notmuch-saved-searches)
+   ;; Use a copy, since the sorting
+   ;; function may have side effects,
+   ;; e.g. if it just `sort's the input.
+   (copy-sequence notmuch-saved-searches))
 notmuch-saved-searches)
   :show-empty-searches notmuch-show-empty-saved-searches))
found-target-pos)
-- 
1.7.9.1

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

Re: [PATCH] emacs-hello: Do not calculate the count of the messages in hidden sections

[Daniel Schoepe]

On Thu, 01 Mar 2012 22:18:04 +, Mark Walters markwalters1...@gmail.com 
wrote:
 This looks fine to me and does speed things up when the All tags
 section is hidden (are there other sections I can hide?)

You can define other section that you can then hide, which was the main
point of the original patch.

Michal, your patch looks good to me too. Now that my two patches have
been pushed, I think this should go in as well.

Cheers,
Daniel


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

Re: [PATCH] emacs-hello: Do not calculate the count of the messages in hidden sections

[Daniel Schoepe]

On Fri, 02 Mar 2012 01:34:03 +0100, Daniel Schoepe dan...@schoepe.org wrote:
 You can define other section that you can then hide, which was the main
 point of the original patch.

The defining other sections thing that is, not that you have more
things to hide.. :)


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

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

[Daniel Schoepe]

On Sun, 26 Feb 2012 11:22:10 +, Patrick Totzke  wrote:
> > so it would seem more appropriate that this be done in the backend.
> I agree. I personally think this is a nice feature to have in all
> user interfaces to notmuch and therefore it makes sense to implement it once
> in the lib. Also because ~/.notmuch-config already contains a list of my 
> addresses
> and therefore should have all information needed.

I'm not sure if that's a good idea: A frontend might want to make this
configurable, for example to give the user the opportunity to disable it
(possibly to see to which of his mail adresses he used in that thread,
if they have different real name components). It might also get tricky
to distinguish between someone called "me" participating in the thread
and the user, which might be relevant for highlighting the latter case
differently, while it's rather easy for a frontend to do the
transformation itself.

At least it should not be done in the library, because it'd need to read
the user's addresses from configuration file which the library is not
supposed to access, as far as I understand.

Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

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

[Daniel Schoepe]

On Sun, 26 Feb 2012 11:22:10 +, Patrick Totzke 
patricktot...@googlemail.com wrote:
  so it would seem more appropriate that this be done in the backend.
 I agree. I personally think this is a nice feature to have in all
 user interfaces to notmuch and therefore it makes sense to implement it once
 in the lib. Also because ~/.notmuch-config already contains a list of my 
 addresses
 and therefore should have all information needed.

I'm not sure if that's a good idea: A frontend might want to make this
configurable, for example to give the user the opportunity to disable it
(possibly to see to which of his mail adresses he used in that thread,
if they have different real name components). It might also get tricky
to distinguish between someone called me participating in the thread
and the user, which might be relevant for highlighting the latter case
differently, while it's rather easy for a frontend to do the
transformation itself.

At least it should not be done in the library, because it'd need to read
the user's addresses from configuration file which the library is not
supposed to access, as far as I understand.

Cheers,
Daniel


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

nomuch_addresses.py

[Daniel Schoepe]

On Tue, 21 Feb 2012 09:15:09 -, Justus Winter <4winter at 
informatik.uni-hamburg.de> wrote:
> Quoting Daniel Schoepe (2012-02-17 02:28:52) [emphasis mine]:
> >Just for completeness: I'm using the nice nottoomuch-addresses.pl script
> >[1] by Tomi Ollila *which doesn't require any bindings* and is incredibly
> >fast (after generating an initial address database).
> 
> I don't get it. The perl script isn't using any library bindings,
> mainly because there are no libnotmuch bindings for perl. *But* it
> does call the notmuch binary which is worse:

I think that emphasis you added may be a bit misleading:

I specifically mentioned that it doesn't need bindings, because the
initial problem in this thread had to do with missing bindings, not
because I think it's inherently a good thing.

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.

> * incredibly high overhead (fork) compared to a simple function
>   call (plus maybe some kind of ffi)

I think nottoomuch-addresses.sh is a good example how such performance
considerations can be outweighed by choosing a good "algorithm" instead
(extracting all addresses beforehand).

> * manual and error prone serialization of ''function arguments''
> * manual and error prone deserialization of ''return values''
> * very limited error reporting and handling capabilities
> * any kind of resource (think handle to a xapian database) is lost if
>   the process exists resulting in further overhead if the binary is
>   called multiple times
> 
> I do get the feeling that it is perceived as desirable not to require
> any kind of notmuch bindings (David once said something similar about
> nmbug).

While I don't think that using bindings is a bad thing, the fact that we
can do non-trivial things like nmbug without them, seems to be a good
indicator for the quality of the command line interface though. (And
hence notmuch lends itself well to being used in shell scripts).

Cheers,
Daniel

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120221/70f77db7/attachment.pgp>

Re: nomuch_addresses.py

[Daniel Schoepe]

On Tue, 21 Feb 2012 09:15:09 -, Justus Winter 
4win...@informatik.uni-hamburg.de wrote:
 Quoting Daniel Schoepe (2012-02-17 02:28:52) [emphasis mine]:
 Just for completeness: I'm using the nice nottoomuch-addresses.pl script
 [1] by Tomi Ollila *which doesn't require any bindings* and is incredibly
 fast (after generating an initial address database).
 
 I don't get it. The perl script isn't using any library bindings,
 mainly because there are no libnotmuch bindings for perl. *But* it
 does call the notmuch binary which is worse:

I think that emphasis you added may be a bit misleading:

I specifically mentioned that it doesn't need bindings, because the
initial problem in this thread had to do with missing bindings, not
because I think it's inherently a good thing.

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.

 * incredibly high overhead (forkexec) compared to a simple function
   call (plus maybe some kind of ffi)

I think nottoomuch-addresses.sh is a good example how such performance
considerations can be outweighed by choosing a good algorithm instead
(extracting all addresses beforehand).

 * manual and error prone serialization of ''function arguments''
 * manual and error prone deserialization of ''return values''
 * very limited error reporting and handling capabilities
 * any kind of resource (think handle to a xapian database) is lost if
   the process exists resulting in further overhead if the binary is
   called multiple times
 
 I do get the feeling that it is perceived as desirable not to require
 any kind of notmuch bindings (David once said something similar about
 nmbug).

While I don't think that using bindings is a bad thing, the fact that we
can do non-trivial things like nmbug without them, seems to be a good
indicator for the quality of the command line interface though. (And
hence notmuch lends itself well to being used in shell scripts).

Cheers,
Daniel



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

[PATCH] emacs: Add configurable wrapping width for notmuch-wash-wrap-long-lines

[Daniel Schoepe]

On Fri, 17 Feb 2012 18:46:21 +, David Edmondson  wrote:
> * daniel at schoepe.org [2012-02-17 Fri 18:34]
> > This introduces a variable to control after how many characters a line
> > is wrapped by notmuch-wash-wrap-long-lines (still wrapping at the
> > window width if it is lower).
> 
> What do you use this for?

I sometimes get mails with very long lines, but find them more readable
when they are wrapped after 80 characters (of course, this may screw up
source code listings with long lines). 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH] emacs: Add configurable wrapping width for notmuch-wash-wrap-long-lines

[Daniel Schoepe]

This introduces a variable to control after how many characters a line
is wrapped by notmuch-wash-wrap-long-lines (still wrapping at the
window width if it is lower).
---
 emacs/notmuch-wash.el |   36 ++--
 1 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el
index 56981d0..7d003a2 100644
--- a/emacs/notmuch-wash.el
+++ b/emacs/notmuch-wash.el
@@ -87,6 +87,14 @@ If there is one more line than the sum of
 `notmuch-wash-citation-lines-suffix', show that, otherwise
 collapse the remaining lines into a button.")

+(defvar notmuch-wash-wrap-lines-length nil
+  "Wrap line after at most this many characters.
+
+If this is nil, lines in messages will be wrapped to fit in the
+current window. If this is a number, lines will be wrapped after
+this many characters or at the window width (whichever one is
+lower).")
+
 (defun notmuch-wash-toggle-invisible-action (cite-button)
   (let ((invis-spec (button-get cite-button 'invisibility-spec)))
 (if (invisible-p invis-spec)
@@ -276,16 +284,24 @@ Perform several transformations on the message body:
 ;;

 (defun notmuch-wash-wrap-long-lines (msg depth)
-  "Wrap any long lines in the message to the width of the window.
-
-When doing so, maintaining citation leaders in the wrapped text."
-
-  (let ((coolj-wrap-follows-window-size nil)
-   (fill-column (- (window-width)
-   depth
-   ;; 2 to avoid poor interaction with
-   ;; `word-wrap'.
-   2)))
+  "Wrap long lines in the message.
+
+If `notmuch-wash-wrap-lines-length' is a number, this will wrap
+the message lines to the minimum of the width of the window or
+its value. Otherwise, this function will wrap long lines in the
+message at the window width. When doing so, citation leaders in
+the wrapped text are maintained."
+
+  (let* ((coolj-wrap-follows-window-size nil)
+(limit (if (numberp notmuch-wash-wrap-lines-length)
+   (min notmuch-wash-wrap-lines-length
+(window-width))
+ (window-width)))
+(fill-column (- limit
+depth
+;; 2 to avoid poor interaction with
+;; `word-wrap'.
+2)))
 (coolj-wrap-region (point-min) (point-max

 ;;
-- 
1.7.9

nomuch_addresses.py

[Daniel Schoepe]

On Thu, 16 Feb 2012 14:12:36 -0500, Philippe LeCavalier  wrote:
> Hi again.
> 
> 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?

Just for completeness: I'm using the nice nottoomuch-addresses.pl script
[1] by Tomi Ollila which doesn't require any bindings and is incredibly
fast (after generating an initial address database).

Disclaimer: I never tried the python script, so I can't really give a
useful comparison.

[1] id:"m2d3c8e22v.fsf at guru.guru-group.fi"

Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH] emacs: Add configurable wrapping width for notmuch-wash-wrap-long-lines

[Daniel Schoepe]

This introduces a variable to control after how many characters a line
is wrapped by notmuch-wash-wrap-long-lines (still wrapping at the
window width if it is lower).
---
 emacs/notmuch-wash.el |   36 ++--
 1 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el
index 56981d0..7d003a2 100644
--- a/emacs/notmuch-wash.el
+++ b/emacs/notmuch-wash.el
@@ -87,6 +87,14 @@ If there is one more line than the sum of
 `notmuch-wash-citation-lines-suffix', show that, otherwise
 collapse the remaining lines into a button.)
 
+(defvar notmuch-wash-wrap-lines-length nil
+  Wrap line after at most this many characters.
+
+If this is nil, lines in messages will be wrapped to fit in the
+current window. If this is a number, lines will be wrapped after
+this many characters or at the window width (whichever one is
+lower).)
+
 (defun notmuch-wash-toggle-invisible-action (cite-button)
   (let ((invis-spec (button-get cite-button 'invisibility-spec)))
 (if (invisible-p invis-spec)
@@ -276,16 +284,24 @@ Perform several transformations on the message body:
 ;;
 
 (defun notmuch-wash-wrap-long-lines (msg depth)
-  Wrap any long lines in the message to the width of the window.
-
-When doing so, maintaining citation leaders in the wrapped text.
-
-  (let ((coolj-wrap-follows-window-size nil)
-   (fill-column (- (window-width)
-   depth
-   ;; 2 to avoid poor interaction with
-   ;; `word-wrap'.
-   2)))
+  Wrap long lines in the message.
+
+If `notmuch-wash-wrap-lines-length' is a number, this will wrap
+the message lines to the minimum of the width of the window or
+its value. Otherwise, this function will wrap long lines in the
+message at the window width. When doing so, citation leaders in
+the wrapped text are maintained.
+
+  (let* ((coolj-wrap-follows-window-size nil)
+(limit (if (numberp notmuch-wash-wrap-lines-length)
+   (min notmuch-wash-wrap-lines-length
+(window-width))
+ (window-width)))
+(fill-column (- limit
+depth
+;; 2 to avoid poor interaction with
+;; `word-wrap'.
+2)))
 (coolj-wrap-region (point-min) (point-max
 
 ;;
-- 
1.7.9

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

Re: [PATCH] emacs: Add configurable wrapping width for notmuch-wash-wrap-long-lines

[Daniel Schoepe]

On Fri, 17 Feb 2012 18:46:21 +, David Edmondson d...@dme.org wrote:
 * dan...@schoepe.org [2012-02-17 Fri 18:34]
  This introduces a variable to control after how many characters a line
  is wrapped by notmuch-wash-wrap-long-lines (still wrapping at the
  window width if it is lower).
 
 What do you use this for?

I sometimes get mails with very long lines, but find them more readable
when they are wrapped after 80 characters (of course, this may screw up
source code listings with long lines). 


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

Re: nomuch_addresses.py

[Daniel Schoepe]

On Thu, 16 Feb 2012 14:12:36 -0500, Philippe LeCavalier 
supp...@plecavalier.com wrote:
 Hi again.
 
 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?

Just for completeness: I'm using the nice nottoomuch-addresses.pl script
[1] by Tomi Ollila which doesn't require any bindings and is incredibly
fast (after generating an initial address database).

Disclaimer: I never tried the python script, so I can't really give a
useful comparison.

[1] id:m2d3c8e22v@guru.guru-group.fi

Cheers,
Daniel


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

[PATCH] emacs: allow to set RETAIN-STATE for `notmuch-show-refresh-view' interactively

[Daniel Schoepe]

On Mon, 13 Feb 2012 10:29:26 -0500, Austin Clements  wrote:
> Quoth Dmitry Kurochkin on Feb 13 at  3:09 pm:
> > The notmuch-show view refresh function (`notmuch-show-refresh-view',
> > bound to "=") accepts an optional RETAIN-STATE argument.  The patch
> > allows to set this argument interactively by using "C-u =".
> 
> Why do we not *always* want this?

Seconded. And I don't think making that the default along with an easy
way to get the old behavior is "too much" for one patch, even though
"put that in a separate commit!" is a fairly common sentiment here, and
not a bad one, most of the time.

Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: [PATCH] emacs: allow to set RETAIN-STATE for `notmuch-show-refresh-view' interactively

[Daniel Schoepe]

On Mon, 13 Feb 2012 10:29:26 -0500, Austin Clements amdra...@mit.edu wrote:
 Quoth Dmitry Kurochkin on Feb 13 at  3:09 pm:
  The notmuch-show view refresh function (`notmuch-show-refresh-view',
  bound to =) accepts an optional RETAIN-STATE argument.  The patch
  allows to set this argument interactively by using C-u =.
 
 Why do we not *always* want this?

Seconded. And I don't think making that the default along with an easy
way to get the old behavior is too much for one patch, even though
put that in a separate commit! is a fairly common sentiment here, and
not a bad one, most of the time.

Cheers,
Daniel


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

[RFC PATCH v2 1/3] cli: notmuch-show changes to support pick

[Daniel Schoepe]

On Sun, 12 Feb 2012 18:49:37 +, Mark Walters  
wrote:
> +int opt_index, ret, entire_thread;
> +notmuch_sort_t sort = NOTMUCH_SORT_NEWEST_FIRST;
>  const notmuch_show_format_t *format = _text;
>  notmuch_show_params_t params = { .part = -1 };
>  int format_sel = NOTMUCH_FORMAT_NOT_SPECIFIED;
>  notmuch_bool_t verify = FALSE;
> +notmuch_bool_t headers_only = FALSE;
>  
>  notmuch_opt_desc_t options[] = {
>   { NOTMUCH_OPT_KEYWORD, _sel, "format", 'f',
> @@ -1042,10 +1093,19 @@ notmuch_show_command (void *ctx, unused (int argc), 
> unused (char *argv[]))
> { "mbox", NOTMUCH_FORMAT_MBOX },
> { "raw", NOTMUCH_FORMAT_RAW },
> { 0, 0 } } },
> + { NOTMUCH_OPT_KEYWORD, , "sort", 's',
> +   (notmuch_keyword_t []){ { "oldest-first", NOTMUCH_SORT_OLDEST_FIRST },
> +   { "newest-first", NOTMUCH_SORT_NEWEST_FIRST },
> +   { 0, 0 } } },
>   { NOTMUCH_OPT_INT, , "part", 'p', 0 },
> - { NOTMUCH_OPT_BOOLEAN, _thread, "entire-thread", 't', 0 },
> + { NOTMUCH_OPT_KEYWORD, _thread, "thread", 't',
> +   (notmuch_keyword_t []){ { "match", NOTMUCH_SHOW_THREAD_MATCH, },
> +   { "entire", NOTMUCH_SHOW_THREAD_ENTIRE },
> +   { "none", NOTMUCH_SHOW_THREAD_NONE },
> +   { 0, 0 } } },
>   { NOTMUCH_OPT_BOOLEAN, , "decrypt", 'd', 0 },
>   { NOTMUCH_OPT_BOOLEAN, , "verify", 'v', 0 },
> + { NOTMUCH_OPT_BOOLEAN, _only, "headers-only", 'h', 0 },
>   { 0, 0, 0, 0, 0 }
>  };
>  
> @@ -1055,6 +1115,9 @@ notmuch_show_command (void *ctx, unused (int argc), 
> unused (char *argv[]))
>   return 1;
>  }
>  
> +params.entire_thread = entire_thread;

entire_thread is not initialized here, if there is no --thread
argument. The rest of the code makes this result in the same behavior as
--thread=entire, but it should be initialized to
NOTMUCH_SHOW_THREAD_MATCH.

Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

RFC notmuch-pick: an emacs threaded message view with split-pane

[Daniel Schoepe]

On Sun, 12 Feb 2012 12:46:36 -0800, Jameson Graef Rollins  wrote:
> Hey, Mark.  I really like the idea, since I've been looking for
> something like this for a while, but there's something I'm confused
> about.  Is this meant to replace notmuch-search, or notmuch-show?  I had
> been hoping for a notmuch *show* replacement that shows the nice tree
> view for the thread, with a single message view below.  But it sounds
> like you're meant to be replacing notmuch search?  That seems confusing
> to me, particularly in light of the big performance hit you describe.

As far as I can tell, it is intended as a third option and can be used
for both, viewing all messages matching a search in a tree structure
(with a pane for an individual message) as in most other mail clients
(mutt, thunderbird, Gnus, etc.) and viewing a single thread in the
manner you described.

This has the added bonus, that it can be offered _in addition_ to show
in search, since I wouldn't want to give up the current
search-view. notmuch-show might also be preferred by some users (due to
its similarity to sup and gmail). Of course, this would mean that we
would have to maintain threading capabilities for two modes. (It relies
on show for displaying a single message, so that part is not
duplicated).

Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH v4 1/2] emacs: Add thread-outline functionality

[Daniel Schoepe]

I think notmuch-pick [1] is a better approach and also provides
thread-outlining, so these patches should be obsolete now.

[1] id:"87d39k1gvi.fsf at qmul.ac.uk"

Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH 0/1] emacs: Make highlight-faces for pick configurable

[Daniel Schoepe]

This makes the faces notmuch-pick uses for high/"low"lighting configurable.
Obviously, this requires the rest of the patch series from this thread.

RFC notmuch-pick: an emacs threaded message view with split-pane

[Daniel Schoepe]

Forgot to reply to the list

On Sun, 12 Feb 2012 10:32:48 +, Mark Walters  
wrote:
> Questions/thoughts and known bugs:
> 
> Do people like the rough idea? 

I think it's a great idea. What I find especially nice about this, is
that it works for both, just showing the structure of one thread and the
traditional all-messages-matching-a-search view. I've actually rebound
 in notmuch-search to this and it works great so far:

(defun notmuch-search-pick ()
  "Show the selected thread with notmuch-pick"
  (interactive)
  (notmuch-pick (notmuch-search-find-thread-id)
notmuch-search-query-string
(notmuch-prettify-subject (notmuch-search-find-subject)))
  (unless (notmuch-pick-get-match)
(notmuch-pick-next-message))
  (notmuch-pick-show-message))

> At the moment there is some shared code with notmuch-show.el. This could
> be factored out: however, while this pick mode is WIP I don't think it
> is worth it. I have tried to keep the impact on the current parts of the
> emacs code and the command line interface fairly small.
> 
> I will send the patches as 3 bits: one is the command-line support
> needed (i.e. changes to notmuch-show.c) one is the changes to the other
> emacs files and the final one is the notmuch-pick.el file itself.
> 
> There are some things that need fixing: some of which are marked in the
> code. For example the highlighting (lowlighting?) of non-matching
> messages is hard-wired gray and should be a defcustom. The tags are not
> in a nice tag face and do not update automatically. There should be an
> option not to use the split-screen mode.

Yeah, the hardcoded "black" is also pretty annoying if one uses a
black background. :)
I'll send a patch fixing that later.

> Anyway I am already finding it useful: show a long thread, press 'Z' to
> see the thread structure nicely and then ...

Yeah, that's basically my main use case, as I don't like dozens of
messages of the same thread cluttering up all the search results
(e.g. for tag:notmuch).

Thanks for the great work David and Mark, I've really been looking
forward to something that makes my half-baked attempt at thread
outlining [1] obsolete. :)

[1] id:"1324082126-25404-1-git-send-email-daniel at schoepe.org"

Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH 0/1] emacs: Make highlight-faces for pick configurable

[Daniel Schoepe]

This makes the faces notmuch-pick uses for high/lowlighting configurable.
Obviously, this requires the rest of the patch series from this thread.

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

[PATCH] emacs: Make highlight-faces for pick configurable

[Daniel Schoepe]

---
 emacs/notmuch-pick.el |   21 ++---
 1 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/emacs/notmuch-pick.el b/emacs/notmuch-pick.el
index 4c91d7c..2bf1ae4 100644
--- a/emacs/notmuch-pick.el
+++ b/emacs/notmuch-pick.el
@@ -42,6 +42,22 @@
   :group 'notmuch
   :type 'int)
 
+(defface notmuch-pick-match-face
+  'class color)
+  (background dark))
+ (:foreground white))
+(((class color)
+  (background light))
+ (:foreground black))
+(t (:bold t)))
+  Face used in pick mode for matching messages.
+  :group 'notmuch)
+
+(defface notmuch-pick-no-match-face
+  '((t (:foreground gray)))
+  Face used in pick mode for messages not matching the query.
+  :group 'notmuch)
+
 (defvar notmuch-pick-previous-subject )
 (make-variable-buffer-local 'notmuch-pick-previous-subject)
 
@@ -415,10 +431,9 @@ unchanged ADDRESS if parsing fails.
 (match (plist-get msg :match))
 (tags (plist-get msg :tags))
 (bare-subject (notmuch-show-strip-re (plist-get headers :Subject)))
-;; Face should be a defcustom or something MJW
 (message-face (if match
-  '(:foreground black)
-  '(:foreground gray
+  'notmuch-pick-match-face
+'notmuch-pick-no-match-face)))
 
 (insert (propertize (concat
 (notmuch-pick-string-width
-- 
1.7.9

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

Re: [PATCH v4 1/2] emacs: Add thread-outline functionality

[Daniel Schoepe]

I think notmuch-pick [1] is a better approach and also provides
thread-outlining, so these patches should be obsolete now.

[1] id:87d39k1gvi@qmul.ac.uk

Cheers,
Daniel


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

Re: RFC notmuch-pick: an emacs threaded message view with split-pane

[Daniel Schoepe]

On Sun, 12 Feb 2012 12:46:36 -0800, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 Hey, Mark.  I really like the idea, since I've been looking for
 something like this for a while, but there's something I'm confused
 about.  Is this meant to replace notmuch-search, or notmuch-show?  I had
 been hoping for a notmuch *show* replacement that shows the nice tree
 view for the thread, with a single message view below.  But it sounds
 like you're meant to be replacing notmuch search?  That seems confusing
 to me, particularly in light of the big performance hit you describe.

As far as I can tell, it is intended as a third option and can be used
for both, viewing all messages matching a search in a tree structure
(with a pane for an individual message) as in most other mail clients
(mutt, thunderbird, Gnus, etc.) and viewing a single thread in the
manner you described.

This has the added bonus, that it can be offered _in addition_ to show
in search, since I wouldn't want to give up the current
search-view. notmuch-show might also be preferred by some users (due to
its similarity to sup and gmail). Of course, this would mean that we
would have to maintain threading capabilities for two modes. (It relies
on show for displaying a single message, so that part is not
duplicated).

Cheers,
Daniel


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

Re: [RFC PATCH v2 1/3] cli: notmuch-show changes to support pick

[Daniel Schoepe]

On Sun, 12 Feb 2012 18:49:37 +, Mark Walters markwalters1...@gmail.com 
wrote:
 +int opt_index, ret, entire_thread;
 +notmuch_sort_t sort = NOTMUCH_SORT_NEWEST_FIRST;
  const notmuch_show_format_t *format = format_text;
  notmuch_show_params_t params = { .part = -1 };
  int format_sel = NOTMUCH_FORMAT_NOT_SPECIFIED;
  notmuch_bool_t verify = FALSE;
 +notmuch_bool_t headers_only = FALSE;
  
  notmuch_opt_desc_t options[] = {
   { NOTMUCH_OPT_KEYWORD, format_sel, format, 'f',
 @@ -1042,10 +1093,19 @@ notmuch_show_command (void *ctx, unused (int argc), 
 unused (char *argv[]))
 { mbox, NOTMUCH_FORMAT_MBOX },
 { raw, NOTMUCH_FORMAT_RAW },
 { 0, 0 } } },
 + { NOTMUCH_OPT_KEYWORD, sort, sort, 's',
 +   (notmuch_keyword_t []){ { oldest-first, NOTMUCH_SORT_OLDEST_FIRST },
 +   { newest-first, NOTMUCH_SORT_NEWEST_FIRST },
 +   { 0, 0 } } },
   { NOTMUCH_OPT_INT, params.part, part, 'p', 0 },
 - { NOTMUCH_OPT_BOOLEAN, params.entire_thread, entire-thread, 't', 0 },
 + { NOTMUCH_OPT_KEYWORD, entire_thread, thread, 't',
 +   (notmuch_keyword_t []){ { match, NOTMUCH_SHOW_THREAD_MATCH, },
 +   { entire, NOTMUCH_SHOW_THREAD_ENTIRE },
 +   { none, NOTMUCH_SHOW_THREAD_NONE },
 +   { 0, 0 } } },
   { NOTMUCH_OPT_BOOLEAN, params.decrypt, decrypt, 'd', 0 },
   { NOTMUCH_OPT_BOOLEAN, verify, verify, 'v', 0 },
 + { NOTMUCH_OPT_BOOLEAN, headers_only, headers-only, 'h', 0 },
   { 0, 0, 0, 0, 0 }
  };
  
 @@ -1055,6 +1115,9 @@ notmuch_show_command (void *ctx, unused (int argc), 
 unused (char *argv[]))
   return 1;
  }
  
 +params.entire_thread = entire_thread;

entire_thread is not initialized here, if there is no --thread
argument. The rest of the code makes this result in the same behavior as
--thread=entire, but it should be initialized to
NOTMUCH_SHOW_THREAD_MATCH.

Cheers,
Daniel


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

[PATCH v7 2/2] emacs: Tests for user-defined sections

[Daniel Schoepe]

Hi Dmitry.

On Sun, 29 Jan 2012 02:48, Dmitry Kurochkin  
wrote:
> I only meant trailing whitespaces in test/emacs file in the lines added
> by the patch.  Trailing whitespaces in expected results are obviously
> fine.

Ah, okay. I fixed those with delete-trailing-whitespace, but then
noticed that this also corrected some trailing whitespace in unrelated
tests, reverted that and then forgot about the trailing whitespace in my
tests by the time I responded.

> I think splitting emacs tests based on -hello, -show and -search views
> is a good idea.  Splitting existing tests is out of scope of this
> patch.  But I think it may be a good opportunity to add a new file with
> -hello tests.

You're right; I'll do that if you find other flaws in your next
review. Otherwise, I'll just put it in another patch.

Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH v8 2/2] emacs: Tests for user-defined sections

[Daniel Schoepe]

From: Daniel Schoepe <daniel.scho...@googlemail.com>

---
 test/emacs |   37 
 test/emacs.expected-output/notmuch-hello   |3 +-
 .../notmuch-hello-new-section  |4 ++
 .../notmuch-hello-no-saved-searches|3 +-
 .../notmuch-hello-section-counts   |5 +++
 .../notmuch-hello-section-hidden-tag   |4 ++
 .../notmuch-hello-section-with-empty   |4 ++
 .../emacs.expected-output/notmuch-hello-with-empty |3 +-
 8 files changed, 60 insertions(+), 3 deletions(-)
 create mode 100644 test/emacs.expected-output/notmuch-hello-new-section
 create mode 100644 test/emacs.expected-output/notmuch-hello-section-counts
 create mode 100644 test/emacs.expected-output/notmuch-hello-section-hidden-tag
 create mode 100644 test/emacs.expected-output/notmuch-hello-section-with-empty

diff --git a/test/emacs b/test/emacs
index 8ca4c8a..93445d7 100755
--- a/test/emacs
+++ b/test/emacs
@@ -29,6 +29,43 @@ test_emacs '(let ((notmuch-saved-searches
  (test-output))'
 test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-no-saved-searches

+test_begin_subtest "User defined section with inbox tag"
+test_emacs "(let ((notmuch-hello-sections
+   (list (lambda () (notmuch-hello-insert-searches
+ \"Test\" '((\"inbox\" . 
\"tag:inbox\")))
+   (notmuch-hello)
+   (test-output))"
+test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-new-section
+
+test_begin_subtest "User defined section with empty, hidden entry"
+test_emacs "(let ((notmuch-hello-sections
+   (list (lambda () (notmuch-hello-insert-searches
+ \"Test-with-empty\"
+ '((\"inbox\" . \"tag:inbox\")
+   (\"doesnotexist\" . 
\"tag:doesnotexist\"))
+ :hide-empty-searches t)
+ (notmuch-hello)
+ (test-output))"
+test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-section-with-empty
+
+test_begin_subtest "User defined section, unread tag filtered out"
+test_emacs "(let ((notmuch-hello-sections
+   (list (lambda () (notmuch-hello-insert-tags-section
+ \"Test-with-filtered\"
+ :hide-tags '(\"unread\"))
+ (notmuch-hello)
+ (test-output))"
+test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-section-hidden-tag
+
+test_begin_subtest "User defined section, different query for counts"
+test_emacs "(let ((notmuch-hello-sections
+   (list (lambda () (notmuch-hello-insert-tags-section
+ \"Test-with-counts\"
+ :filter-count \"tag:signed\")
+ (notmuch-hello)
+ (test-output))"
+test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-section-counts
+
 test_begin_subtest "Basic notmuch-search view in emacs"
 test_emacs '(notmuch-search "tag:inbox")
(notmuch-test-wait)
diff --git a/test/emacs.expected-output/notmuch-hello 
b/test/emacs.expected-output/notmuch-hello
index 3e59595..1470790 100644
--- a/test/emacs.expected-output/notmuch-hello
+++ b/test/emacs.expected-output/notmuch-hello
@@ -6,9 +6,10 @@ Saved searches: [edit]

 Search: .

-[Show all tags]
+All tags: [show]

 Type a search query and hit RET to view matching threads.
Edit saved searches with the `edit' button.
   Hit RET or click on a saved search or tag name to view matching threads.
   `=' to refresh this screen. `s' to search messages. `q' to quit.
+   Customize this page.
diff --git a/test/emacs.expected-output/notmuch-hello-new-section 
b/test/emacs.expected-output/notmuch-hello-new-section
new file mode 100644
index 000..c64d712
--- /dev/null
+++ b/test/emacs.expected-output/notmuch-hello-new-section
@@ -0,0 +1,4 @@
+Test: [hide]
+
+ 52 inbox  
+
diff --git a/test/emacs.expected-output/notmuch-hello-no-saved-searches 
b/test/emacs.expected-output/notmuch-hello-no-saved-searches
index ef0e5d0..05475b1 100644
--- a/test/emacs.expected-output/notmuch-hello-no-saved-searches
+++ b/test/emacs.expected-output/notmuch-hello-no-saved-searches
@@ -2,9 +2,10 @@

 Search: .

-[Show all tags]
+All tags: [show]

 Type a search query and hit RET to view matching threads.
Edit saved searches with the `edit' button.
   Hit RET or clic

[PATCH v8 1/2] emacs: User-defined sections in notmuch-hello

[Daniel Schoepe]

From: Daniel Schoepe <daniel.scho...@googlemail.com>

This patch makes the notmuch-hello screen fully customizable
by allowing the user to add and remove arbitrary sections. It
also provides some convenience functions for constructing sections,
e.g. showing the unread message count for each tag.

This is done by specifying a list of functions that will be run
when notmuch-hello is invoked.
---
 emacs/notmuch-hello.el |  637 +---
 1 files changed, 437 insertions(+), 200 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index d17a30f..0decac2 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -154,6 +154,116 @@ International Bureau of Weights and Measures."
 (defvar notmuch-hello-url "http://notmuchmail.org;
   "The `notmuch' web site.")

+(defvar notmuch-hello-recent-searches nil)
+
+(defvar notmuch-hello-search-pos nil
+  "Position of search widget, if any.
+
+This should only be set by `notmuch-hello-insert-search'.")
+
+(defvar notmuch-hello-custom-section-options
+  '((:filter (string :tag "Filter for each tag"))
+(:filter-count (string :tag "Different filter to generate message counts"))
+(:initially-hidden (const :tag "Hide this section on startup" t))
+(:show-empty-searches (const :tag "Show queries with no matching messages" 
t))
+(:hide-if-empty (const :tag "Hide this section if all queries are empty
+\(and not hidden by show-if-empty)" t)))
+  "Various customization-options for notmuch-hello-tags/query-section.")
+
+(define-widget 'notmuch-hello-tags-section 'lazy
+  "Customize-type for notmuch-hello tag-list sections."
+  :tag "Customized tag-list section (see docstring for details)"
+  :type
+  `(list :tag ""
+(const :tag "" notmuch-hello-insert-tags-section)
+(string :tag "Title for this section")
+(plist
+ :inline t
+ :options
+ ,(append notmuch-hello-custom-section-options
+  '((:hide-tags (repeat :tag "Tags that will be hidden"
+string)))
+
+(define-widget 'notmuch-hello-query-section 'lazy
+  "Customize-type for custom saved-search-like sections"
+  :tag "Customized queries section (see docstring for details)"
+  :type
+  `(list :tag ""
+(const :tag "" notmuch-hello-insert-query-list)
+(string :tag "Title for this section")
+(repeat :tag "Queries"
+(cons (string :tag "Name") (string :tag "Query")))
+(plist :inline t :options ,notmuch-hello-custom-section-options)))
+
+(defcustom notmuch-hello-sections
+  (list #'notmuch-hello-insert-header
+   #'notmuch-hello-insert-saved-searches
+   #'notmuch-hello-insert-search
+   #'notmuch-hello-insert-recent-searches
+   #'notmuch-hello-insert-alltags
+   #'notmuch-hello-insert-footer)
+  "Sections for notmuch-hello.
+
+The list contains functions which are used to construct sections in
+notmuch-hello buffer.  When notmuch-hello buffer is constructed,
+these functions are run in the order they appear in this list.  Each
+function produces a section simply by adding content to the current
+buffer.  A section should not end with an empty line, because a
+newline will be inserted after each section by `notmuch-hello'.
+
+Each function should take no arguments.  If the produced section
+includes `notmuch-hello-target' (i.e. cursor should be positioned
+inside this section), the function should return this element's
+position.
+Otherwise, it should return nil.
+
+For convenience an element can also be a list of the form (FUNC ARG1
+ARG2 .. ARGN) in which case FUNC will be applied to the rest of the
+list.
+
+A \"Customized tag-list section\" item in the customize-interface
+displays a list of all tags, optionally hiding some of them. It
+is also possible to filter the list of messages matching each tag
+by an additional filter query. Similarly, the count of messages
+displayed next to the buttons can be generated by applying a
+different filter to the tag query. These filters are also
+supported for \"Customized queries section\" items."
+  :group 'notmuch
+  :type
+  '(repeat
+(choice (function-item notmuch-hello-insert-header)
+   (function-item notmuch-hello-insert-saved-searches)
+   (function-item notmuch-hello-insert-search)
+   (function-item notmuch-hello-insert-recent-searches)
+   (function-item notmuch-hello-insert-alltags)
+   (function-item notmuch-hello-insert-footer)
+   (function-item notmuch-hello-insert-inbox)
+   notmuch-hello-tags-section
+   notmuch-hello-query-section
+   (function :tag "Custom section"
+
+(d

[PATCH v8 0/2] emacs: User-defined sections in notmuch-hello

[Daniel Schoepe]

Rebased against master.

[PATCH v7 2/2] emacs: Tests for user-defined sections

[Daniel Schoepe]

Hi Dmitry,

On Tue, 24 Jan 2012 03:07, Dmitry Kurochkin  
wrote:
> There are some trailing whitespaces in the tests.

those are also produced by the various notmuch-hello functions, and are
also in the existing tests. If someone is bothered by this, it should be
fixed in a separate patch.

> 
> Also, please consider moving the hello sections tests to a separate file
> (emacs-hello-sections, perhaps?).  I am worried that test/emacs file
> becomes too big.  And we will probably add more notmuch-hello
> section-related tests in the future.

I think it's better to split it up into more than just
emacs-hello-sections and emacs, as there are also quite a few tests
relating solely to, e.g., -show or -search.

Anyhow, I'll send another rebased version fixing conflicts with the
search-interface changes.

Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH v8 0/2] emacs: User-defined sections in notmuch-hello

[Daniel Schoepe]

Rebased against master.

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

[PATCH v8 1/2] emacs: User-defined sections in notmuch-hello

[Daniel Schoepe]

From: Daniel Schoepe daniel.scho...@googlemail.com

This patch makes the notmuch-hello screen fully customizable
by allowing the user to add and remove arbitrary sections. It
also provides some convenience functions for constructing sections,
e.g. showing the unread message count for each tag.

This is done by specifying a list of functions that will be run
when notmuch-hello is invoked.
---
 emacs/notmuch-hello.el |  637 +---
 1 files changed, 437 insertions(+), 200 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index d17a30f..0decac2 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -154,6 +154,116 @@ International Bureau of Weights and Measures.
 (defvar notmuch-hello-url http://notmuchmail.org;
   The `notmuch' web site.)
 
+(defvar notmuch-hello-recent-searches nil)
+
+(defvar notmuch-hello-search-pos nil
+  Position of search widget, if any.
+
+This should only be set by `notmuch-hello-insert-search'.)
+
+(defvar notmuch-hello-custom-section-options
+  '((:filter (string :tag Filter for each tag))
+(:filter-count (string :tag Different filter to generate message counts))
+(:initially-hidden (const :tag Hide this section on startup t))
+(:show-empty-searches (const :tag Show queries with no matching messages 
t))
+(:hide-if-empty (const :tag Hide this section if all queries are empty
+\(and not hidden by show-if-empty) t)))
+  Various customization-options for notmuch-hello-tags/query-section.)
+
+(define-widget 'notmuch-hello-tags-section 'lazy
+  Customize-type for notmuch-hello tag-list sections.
+  :tag Customized tag-list section (see docstring for details)
+  :type
+  `(list :tag 
+(const :tag  notmuch-hello-insert-tags-section)
+(string :tag Title for this section)
+(plist
+ :inline t
+ :options
+ ,(append notmuch-hello-custom-section-options
+  '((:hide-tags (repeat :tag Tags that will be hidden
+string)))
+
+(define-widget 'notmuch-hello-query-section 'lazy
+  Customize-type for custom saved-search-like sections
+  :tag Customized queries section (see docstring for details)
+  :type
+  `(list :tag 
+(const :tag  notmuch-hello-insert-query-list)
+(string :tag Title for this section)
+(repeat :tag Queries
+(cons (string :tag Name) (string :tag Query)))
+(plist :inline t :options ,notmuch-hello-custom-section-options)))
+
+(defcustom notmuch-hello-sections
+  (list #'notmuch-hello-insert-header
+   #'notmuch-hello-insert-saved-searches
+   #'notmuch-hello-insert-search
+   #'notmuch-hello-insert-recent-searches
+   #'notmuch-hello-insert-alltags
+   #'notmuch-hello-insert-footer)
+  Sections for notmuch-hello.
+
+The list contains functions which are used to construct sections in
+notmuch-hello buffer.  When notmuch-hello buffer is constructed,
+these functions are run in the order they appear in this list.  Each
+function produces a section simply by adding content to the current
+buffer.  A section should not end with an empty line, because a
+newline will be inserted after each section by `notmuch-hello'.
+
+Each function should take no arguments.  If the produced section
+includes `notmuch-hello-target' (i.e. cursor should be positioned
+inside this section), the function should return this element's
+position.
+Otherwise, it should return nil.
+
+For convenience an element can also be a list of the form (FUNC ARG1
+ARG2 .. ARGN) in which case FUNC will be applied to the rest of the
+list.
+
+A \Customized tag-list section\ item in the customize-interface
+displays a list of all tags, optionally hiding some of them. It
+is also possible to filter the list of messages matching each tag
+by an additional filter query. Similarly, the count of messages
+displayed next to the buttons can be generated by applying a
+different filter to the tag query. These filters are also
+supported for \Customized queries section\ items.
+  :group 'notmuch
+  :type
+  '(repeat
+(choice (function-item notmuch-hello-insert-header)
+   (function-item notmuch-hello-insert-saved-searches)
+   (function-item notmuch-hello-insert-search)
+   (function-item notmuch-hello-insert-recent-searches)
+   (function-item notmuch-hello-insert-alltags)
+   (function-item notmuch-hello-insert-footer)
+   (function-item notmuch-hello-insert-inbox)
+   notmuch-hello-tags-section
+   notmuch-hello-query-section
+   (function :tag Custom section
+
+(defvar notmuch-hello-target nil
+  Button text at position of point before rebuilding the notmuch-buffer.
+
+This variable contains the text of the button, if any, the
+point was positioned at before the notmuch-hello buffer was
+rebuilt. This should never actually be globaly and is defined as a
+defvar only for documentation

Re: [PATCH v7 2/2] emacs: Tests for user-defined sections

[Daniel Schoepe]

Hi Dmitry.

On Sun, 29 Jan 2012 02:48, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote:
 I only meant trailing whitespaces in test/emacs file in the lines added
 by the patch.  Trailing whitespaces in expected results are obviously
 fine.

Ah, okay. I fixed those with delete-trailing-whitespace, but then
noticed that this also corrected some trailing whitespace in unrelated
tests, reverted that and then forgot about the trailing whitespace in my
tests by the time I responded.

 I think splitting emacs tests based on -hello, -show and -search views
 is a good idea.  Splitting existing tests is out of scope of this
 patch.  But I think it may be a good opportunity to add a new file with
 -hello tests.

You're right; I'll do that if you find other flaws in your next
review. Otherwise, I'll just put it in another patch.

Cheers,
Daniel


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

[PATCH v7 2/2] emacs: Tests for user-defined sections

[Daniel Schoepe]

From: Daniel Schoepe <daniel.scho...@googlemail.com>

---
 test/emacs |   37 
 test/emacs.expected-output/notmuch-hello   |4 ++-
 .../notmuch-hello-new-section  |4 ++
 .../notmuch-hello-no-saved-searches|4 ++-
 .../notmuch-hello-section-counts   |5 +++
 .../notmuch-hello-section-hidden-tag   |4 ++
 .../notmuch-hello-section-with-empty   |4 ++
 .../emacs.expected-output/notmuch-hello-with-empty |4 ++-
 8 files changed, 63 insertions(+), 3 deletions(-)
 create mode 100644 test/emacs.expected-output/notmuch-hello-new-section
 create mode 100644 test/emacs.expected-output/notmuch-hello-section-counts
 create mode 100644 test/emacs.expected-output/notmuch-hello-section-hidden-tag
 create mode 100644 test/emacs.expected-output/notmuch-hello-section-with-empty

diff --git a/test/emacs b/test/emacs
index ac47b16..8b1d16c 100755
--- a/test/emacs
+++ b/test/emacs
@@ -29,6 +29,43 @@ test_emacs '(let ((notmuch-saved-searches
  (test-output))'
 test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-no-saved-searches

+test_begin_subtest "User defined section with inbox tag"
+test_emacs "(let ((notmuch-hello-sections 
+   (list (lambda () (notmuch-hello-insert-searches
+ \"Test\" '((\"inbox\" . 
\"tag:inbox\")))
+   (notmuch-hello)
+   (test-output))"
+test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-new-section
+
+test_begin_subtest "User defined section with empty, hidden entry"
+test_emacs "(let ((notmuch-hello-sections 
+   (list (lambda () (notmuch-hello-insert-searches
+ \"Test-with-empty\" 
+ '((\"inbox\" . \"tag:inbox\")
+   (\"doesnotexist\" . 
\"tag:doesnotexist\"))
+ :hide-empty-searches t)
+ (notmuch-hello)
+ (test-output))"
+test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-section-with-empty
+
+test_begin_subtest "User defined section, unread tag filtered out"
+test_emacs "(let ((notmuch-hello-sections 
+   (list (lambda () (notmuch-hello-insert-tags-section
+ \"Test-with-filtered\"
+ :hide-tags '(\"unread\"))
+ (notmuch-hello)
+ (test-output))"
+test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-section-hidden-tag
+
+test_begin_subtest "User defined section, different query for counts"
+test_emacs "(let ((notmuch-hello-sections
+   (list (lambda () (notmuch-hello-insert-tags-section
+ \"Test-with-counts\"
+ :filter-count \"tag:signed\")
+ (notmuch-hello)
+ (test-output))"
+test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-section-counts
+
 test_begin_subtest "Basic notmuch-search view in emacs"
 test_emacs '(notmuch-search "tag:inbox")
(notmuch-test-wait)
diff --git a/test/emacs.expected-output/notmuch-hello 
b/test/emacs.expected-output/notmuch-hello
index 196112e..cf49cb4 100644
--- a/test/emacs.expected-output/notmuch-hello
+++ b/test/emacs.expected-output/notmuch-hello
@@ -6,9 +6,11 @@ Saved searches: [edit]

 Search: .

-[Show all tags]
+All tags: [show]

 Type a search query and hit RET to view matching threads.
Edit saved searches with the `edit' button.
   Hit RET or click on a saved search or tag name to view matching threads.
 `=' refreshes this screen. `s' jumps to the search box. `q' to quit.
+   Customize this page.
+
diff --git a/test/emacs.expected-output/notmuch-hello-new-section 
b/test/emacs.expected-output/notmuch-hello-new-section
new file mode 100644
index 000..c64d712
--- /dev/null
+++ b/test/emacs.expected-output/notmuch-hello-new-section
@@ -0,0 +1,4 @@
+Test: [hide]
+
+ 52 inbox  
+
diff --git a/test/emacs.expected-output/notmuch-hello-no-saved-searches 
b/test/emacs.expected-output/notmuch-hello-no-saved-searches
index f4cfe49..cec0f91 100644
--- a/test/emacs.expected-output/notmuch-hello-no-saved-searches
+++ b/test/emacs.expected-output/notmuch-hello-no-saved-searches
@@ -2,9 +2,11 @@

 Search: .

-[Show all tags]
+All tags: [show]

 Type a search query and hit RET to view matching threads.
Edit saved searches with the `edit' button.
   Hit 

[PATCH v7 1/2] emacs: User-defined sections in notmuch-hello

[Daniel Schoepe]

From: Daniel Schoepe <daniel.scho...@googlemail.com>

This patch makes the notmuch-hello screen fully customizable
by allowing the user to add and remove arbitrary sections. It
also provides some convenience functions for constructing sections,
e.g. showing the unread message count for each tag.

This is done by specifying a list of functions that will be run
when notmuch-hello is invoked.
---
 emacs/notmuch-hello.el |  620 
 1 files changed, 420 insertions(+), 200 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 63f2e07..5ba9a11 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -159,6 +159,101 @@ International Bureau of Weights and Measures."

 (defvar notmuch-hello-recent-searches nil)

+(defvar notmuch-hello-custom-section-options
+  '((:filter (string :tag "Filter for each tag"))
+(:filter-count (string :tag "Different filter to generate message counts"))
+(:initially-hidden (const :tag "Hide this section on startup" t))
+(:show-empty-searches (const :tag "Show queries with no matching messages" 
t))
+(:hide-if-empty (const :tag "Hide this section if all queries are empty
+\(and not hidden by show-if-empty)" t)))
+  "Various customization-options for notmuch-hello-tags/query-section.")
+
+(define-widget 'notmuch-hello-tags-section 'lazy
+  "Customize-type for notmuch-hello tag-list sections."
+  :tag "Customized tag-list section (see docstring for details)"
+  :type
+  `(list :tag ""
+(const :tag "" notmuch-hello-insert-tags-section)
+(string :tag "Title for this section")
+(plist
+ :inline t
+ :options
+ ,(append notmuch-hello-custom-section-options
+  '((:hide-tags (repeat :tag "Tags that will be hidden"
+string)))
+
+(define-widget 'notmuch-hello-query-section 'lazy
+  "Customize-type for custom saved-search-like sections"
+  :tag "Customized queries section (see docstring for details)"
+  :type
+  `(list :tag ""
+(const :tag "" notmuch-hello-insert-query-list)
+(string :tag "Title for this section")
+(repeat :tag "Queries"
+(cons (string :tag "Name") (string :tag "Query")))
+(plist :inline t :options ,notmuch-hello-custom-section-options)))
+
+(defcustom notmuch-hello-sections
+  (list #'notmuch-hello-insert-header
+   #'notmuch-hello-insert-saved-searches
+   #'notmuch-hello-insert-search
+   #'notmuch-hello-insert-recent-searches
+   #'notmuch-hello-insert-alltags
+   #'notmuch-hello-insert-footer)
+  "Sections for notmuch-hello.
+
+The list contains functions which are used to construct sections in
+notmuch-hello buffer.  When notmuch-hello buffer is constructed,
+these functions are run in the order they appear in this list.  Each
+function produces a section simply by adding content to the current
+buffer.  A section should not end with an empty line, because a
+newline will be inserted after each section by `notmuch-hello'.
+
+Each function should take no arguments.  If the produced section
+includes `notmuch-hello-target' (i.e. cursor should be positioned
+inside this section), the function should return this element's
+position.
+Otherwise, it should return nil.
+
+For convenience an element can also be a list of the form (FUNC ARG1
+ARG2 .. ARGN) in which case FUNC will be applied to the rest of the
+list.
+
+A \"Customized tag-list section\" item in the customize-interface
+displays a list of all tags, optionally hiding some of them. It
+is also possible to filter the list of messages matching each tag
+by an additional filter query. Similarly, the count of messages
+displayed next to the buttons can be generated by applying a
+different filter to the tag query. These filters are also
+supported for \"Customized queries section\" items."
+  :group 'notmuch
+  :type
+  '(repeat
+(choice (function-item notmuch-hello-insert-header)
+   (function-item notmuch-hello-insert-saved-searches)
+   (function-item notmuch-hello-insert-search)
+   (function-item notmuch-hello-insert-recent-searches)
+   (function-item notmuch-hello-insert-alltags)
+   (function-item notmuch-hello-insert-footer)
+   (function-item notmuch-hello-insert-inbox)
+   notmuch-hello-tags-section
+   notmuch-hello-query-section
+   (function :tag "Custom section"
+
+(defvar notmuch-hello-target nil
+  "Button text at position of point before rebuilding the notmuch-buffer.
+
+This variable contains the text of the button, if any, the
+point was positioned at before the notmuch-hello buffer was
+rebuilt. Thi

[PATCH v6 1/2] emacs: User-defined sections in notmuch-hello

[Daniel Schoepe]

On Wed, 14 Dec 2011 07:11:21 +0400, Dmitry Kurochkin  wrote:
> Hi Daniel.
> 
> I have finished reviewing this patch at last.  Sorry, it is a bit messy.
> Overall, I like the patch.  It is a very nice improvement.
> 
> I am sure I have missed some important points, but I guess this is the
> best I can do right now.  Perhaps I will find more comments for the next
> version of the patch :)
> 
> As we already discussed on IRC, there are some trailing whitespaces to
> cleanup.
> 
> Here is the review:
> 
> +(defvar notmuch-custom-section-options
> 
> s/notmuch-custom-section-options/notmuch-hello-custom-section-options/
> for consistency?

Agreed.

> 
> +(:filter-count (string :tag "Different filter message counts"))
> 
> It was not clear to me what this option is for from the docstring.
> Perhaps something like: "Count query filter, if different from :filter"?

This option is for displaying a different number of messages next to the
button, than actually match the query the button links to. I think this is
something that was requested a while ago in the context of my patch that
added notmuch-hello-tag-list-make-query.

> +(:initially-hidden (const :tag "Hide this on startup?" t))
> 
> "This" refers to section, right?  If yes, let's state it explicitly:
> "Hide this section on startup".  Also, we should probably remove the
> question mark, or add it to other options for consistency.

Agreed.

> Should the default be to show all sections?

That's the default I'd prefer, since I want to see most of the section
I define by default. If you have some less bike-shedy arguments for
changing this, I'm all ears.

> 
> +(:hide-if-empty (const :tag "Hide if empty" t)))
> 
> As I understand, this controls whether the whole sections is visible.
> It is not clear what "if empty" means.  Does it mean that all queries
> are empty?  Or all queries are empty and :show-empty-sections is
> false?  Consider changing to something like: "Hide this section if all
> queries are empty [and hidden]".

Okay, I'll clarify this in the next version.

> +  `(list :tag ""
> +  (const :tag "" notmuch-hello-insert-query-list)
> 
> Do we need to explicitly specify empty tags?  Aren't they empty by
> default?

It displays the symbol after the const if this is missing.

> 
> +  :tag "Customized tag-list (see docstring for details)"
> +  :tag "Customized queries section (see docstring for details)"
> 
> Perhaps it would be more useful to add reference to
> `notmuch-hello-sections'?  I.e. "see `notmuch-hello-sections' for
> details.

Since this is mainly displayed in the drop-down menu for the section
type in the customize page for notmuch-hello-sections (or
customize-group 'notmuch), references a) don't work there and b)
usually would point to the same thing as the user is currently editing.

> Please s/Customized tag-list/Customized tag-list section/ everywhere for
> consistency (or remove section from "Customized queries section").

Done.

> 
> +Each entry of this list should be a function of no arguments that
> +should return if `notmuch-hello-target' is produced as part of its
> +output and nil otherwise.
> 
> Something is missing between "return if".  IMO it is really hard to
> understand what the function should actually do and what it should
> return.  Are this functions expected to add section content to current
> position?  As I understand, the return value indicates whether cursor
> should be positioned somewhere inside this section.  It is a minor
> detail, but it is described in the first (and complex sentence) as if
> it was the most important part.  Consider moving the return and "no
> arguments" to the 3rd paragraph which describes details about the
> functions.  I would also swap 2nd and 3rd paragraph.  Smth like:
> 
>   The list contains functions which are used to construct sections in
>   notmuch-hello buffer.  When notmuch-hello buffer is constructed,
>   these functions are run in the order they appear in this list.  Each
>   function produces a section simply by adding content to the current
>   buffer.  A section should not end with an empty line, because a
>   newline will be inserted after each section by `notmuch-hello'.
> 
>   Each function should take no arguments.  If the produced section
>   includes `notmuch-hello-target' (i.e. cursor should be positioned
>   inside this section), the function should return [something].
>   Otherwise, it should return nil.
> 
>   For convenience an element can also be a list of the form (FUNC ARG1
>   ARG2 .. ARGN) in which case FUNC will be applied to the rest of the
>   list.
> 
>   [ details about customized tag-list and queries sections ]
> 
> This is just a draft.  Feel free to use it or ignore it.

Thanks, that is quite a bit clearer than what I wrote.

> + For convenience an element can also be
> 
> Remove space the leading space and do `fill-paragraph'.
> 
> + (function :tag "Custom function"
> 
> Perhaps "Custom section" would be more accurate?

Re: [PATCH v6 1/2] emacs: User-defined sections in notmuch-hello

[Daniel Schoepe]

On Wed, 14 Dec 2011 07:11:21 +0400, Dmitry Kurochkin 
dmitry.kuroch...@gmail.com wrote:
 Hi Daniel.
 
 I have finished reviewing this patch at last.  Sorry, it is a bit messy.
 Overall, I like the patch.  It is a very nice improvement.
 
 I am sure I have missed some important points, but I guess this is the
 best I can do right now.  Perhaps I will find more comments for the next
 version of the patch :)
 
 As we already discussed on IRC, there are some trailing whitespaces to
 cleanup.
 
 Here is the review:
 
 +(defvar notmuch-custom-section-options
 
 s/notmuch-custom-section-options/notmuch-hello-custom-section-options/
 for consistency?

Agreed.

 
 +(:filter-count (string :tag Different filter message counts))
 
 It was not clear to me what this option is for from the docstring.
 Perhaps something like: Count query filter, if different from :filter?

This option is for displaying a different number of messages next to the
button, than actually match the query the button links to. I think this is
something that was requested a while ago in the context of my patch that
added notmuch-hello-tag-list-make-query.

 +(:initially-hidden (const :tag Hide this on startup? t))
 
 This refers to section, right?  If yes, let's state it explicitly:
 Hide this section on startup.  Also, we should probably remove the
 question mark, or add it to other options for consistency.

Agreed.

 Should the default be to show all sections?

That's the default I'd prefer, since I want to see most of the section
I define by default. If you have some less bike-shedy arguments for
changing this, I'm all ears.

 
 +(:hide-if-empty (const :tag Hide if empty t)))
 
 As I understand, this controls whether the whole sections is visible.
 It is not clear what if empty means.  Does it mean that all queries
 are empty?  Or all queries are empty and :show-empty-sections is
 false?  Consider changing to something like: Hide this section if all
 queries are empty [and hidden].

Okay, I'll clarify this in the next version.

 +  `(list :tag 
 +  (const :tag  notmuch-hello-insert-query-list)
 
 Do we need to explicitly specify empty tags?  Aren't they empty by
 default?

It displays the symbol after the const if this is missing.

 
 +  :tag Customized tag-list (see docstring for details)
 +  :tag Customized queries section (see docstring for details)
 
 Perhaps it would be more useful to add reference to
 `notmuch-hello-sections'?  I.e. see `notmuch-hello-sections' for
 details.

Since this is mainly displayed in the drop-down menu for the section
type in the customize page for notmuch-hello-sections (or
customize-group 'notmuch), references a) don't work there and b)
usually would point to the same thing as the user is currently editing.

 Please s/Customized tag-list/Customized tag-list section/ everywhere for
 consistency (or remove section from Customized queries section).

Done.

 
 +Each entry of this list should be a function of no arguments that
 +should return if `notmuch-hello-target' is produced as part of its
 +output and nil otherwise.
 
 Something is missing between return if.  IMO it is really hard to
 understand what the function should actually do and what it should
 return.  Are this functions expected to add section content to current
 position?  As I understand, the return value indicates whether cursor
 should be positioned somewhere inside this section.  It is a minor
 detail, but it is described in the first (and complex sentence) as if
 it was the most important part.  Consider moving the return and no
 arguments to the 3rd paragraph which describes details about the
 functions.  I would also swap 2nd and 3rd paragraph.  Smth like:
 
   The list contains functions which are used to construct sections in
   notmuch-hello buffer.  When notmuch-hello buffer is constructed,
   these functions are run in the order they appear in this list.  Each
   function produces a section simply by adding content to the current
   buffer.  A section should not end with an empty line, because a
   newline will be inserted after each section by `notmuch-hello'.
 
   Each function should take no arguments.  If the produced section
   includes `notmuch-hello-target' (i.e. cursor should be positioned
   inside this section), the function should return [something].
   Otherwise, it should return nil.
 
   For convenience an element can also be a list of the form (FUNC ARG1
   ARG2 .. ARGN) in which case FUNC will be applied to the rest of the
   list.
 
   [ details about customized tag-list and queries sections ]
 
 This is just a draft.  Feel free to use it or ignore it.

Thanks, that is quite a bit clearer than what I wrote.

 + For convenience an element can also be
 
 Remove space the leading space and do `fill-paragraph'.
 
 + (function :tag Custom function
 
 Perhaps Custom section would be more accurate?

Yes, it would.

 
 +  Button at position of point before rebuilding the notmuch-buffer
 
 Missing dot 

[PATCH v7 2/2] emacs: Tests for user-defined sections

[Daniel Schoepe]

From: Daniel Schoepe daniel.scho...@googlemail.com

---
 test/emacs |   37 
 test/emacs.expected-output/notmuch-hello   |4 ++-
 .../notmuch-hello-new-section  |4 ++
 .../notmuch-hello-no-saved-searches|4 ++-
 .../notmuch-hello-section-counts   |5 +++
 .../notmuch-hello-section-hidden-tag   |4 ++
 .../notmuch-hello-section-with-empty   |4 ++
 .../emacs.expected-output/notmuch-hello-with-empty |4 ++-
 8 files changed, 63 insertions(+), 3 deletions(-)
 create mode 100644 test/emacs.expected-output/notmuch-hello-new-section
 create mode 100644 test/emacs.expected-output/notmuch-hello-section-counts
 create mode 100644 test/emacs.expected-output/notmuch-hello-section-hidden-tag
 create mode 100644 test/emacs.expected-output/notmuch-hello-section-with-empty

diff --git a/test/emacs b/test/emacs
index ac47b16..8b1d16c 100755
--- a/test/emacs
+++ b/test/emacs
@@ -29,6 +29,43 @@ test_emacs '(let ((notmuch-saved-searches
  (test-output))'
 test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-no-saved-searches
 
+test_begin_subtest User defined section with inbox tag
+test_emacs (let ((notmuch-hello-sections 
+   (list (lambda () (notmuch-hello-insert-searches
+ \Test\ '((\inbox\ . 
\tag:inbox\)))
+   (notmuch-hello)
+   (test-output))
+test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-new-section
+
+test_begin_subtest User defined section with empty, hidden entry
+test_emacs (let ((notmuch-hello-sections 
+   (list (lambda () (notmuch-hello-insert-searches
+ \Test-with-empty\ 
+ '((\inbox\ . \tag:inbox\)
+   (\doesnotexist\ . 
\tag:doesnotexist\))
+ :hide-empty-searches t)
+ (notmuch-hello)
+ (test-output))
+test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-section-with-empty
+
+test_begin_subtest User defined section, unread tag filtered out
+test_emacs (let ((notmuch-hello-sections 
+   (list (lambda () (notmuch-hello-insert-tags-section
+ \Test-with-filtered\
+ :hide-tags '(\unread\))
+ (notmuch-hello)
+ (test-output))
+test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-section-hidden-tag
+
+test_begin_subtest User defined section, different query for counts
+test_emacs (let ((notmuch-hello-sections
+   (list (lambda () (notmuch-hello-insert-tags-section
+ \Test-with-counts\
+ :filter-count \tag:signed\)
+ (notmuch-hello)
+ (test-output))
+test_expect_equal_file OUTPUT $EXPECTED/notmuch-hello-section-counts
+
 test_begin_subtest Basic notmuch-search view in emacs
 test_emacs '(notmuch-search tag:inbox)
(notmuch-test-wait)
diff --git a/test/emacs.expected-output/notmuch-hello 
b/test/emacs.expected-output/notmuch-hello
index 196112e..cf49cb4 100644
--- a/test/emacs.expected-output/notmuch-hello
+++ b/test/emacs.expected-output/notmuch-hello
@@ -6,9 +6,11 @@ Saved searches: [edit]
 
 Search: .
 
-[Show all tags]
+All tags: [show]
 
 Type a search query and hit RET to view matching threads.
Edit saved searches with the `edit' button.
   Hit RET or click on a saved search or tag name to view matching threads.
 `=' refreshes this screen. `s' jumps to the search box. `q' to quit.
+   Customize this page.
+
diff --git a/test/emacs.expected-output/notmuch-hello-new-section 
b/test/emacs.expected-output/notmuch-hello-new-section
new file mode 100644
index 000..c64d712
--- /dev/null
+++ b/test/emacs.expected-output/notmuch-hello-new-section
@@ -0,0 +1,4 @@
+Test: [hide]
+
+ 52 inbox  
+
diff --git a/test/emacs.expected-output/notmuch-hello-no-saved-searches 
b/test/emacs.expected-output/notmuch-hello-no-saved-searches
index f4cfe49..cec0f91 100644
--- a/test/emacs.expected-output/notmuch-hello-no-saved-searches
+++ b/test/emacs.expected-output/notmuch-hello-no-saved-searches
@@ -2,9 +2,11 @@
 
 Search: .
 
-[Show all tags]
+All tags: [show]
 
 Type a search query and hit RET to view matching threads.
Edit saved searches with the `edit' button.
   Hit RET or click on a saved search or tag name to view matching threads.
 `=' refreshes this screen. `s' jumps to the search box. `q' to quit.
+   Customize this page.
+
diff --git a/test/emacs.expected-output/notmuch-hello-section-counts 
b/test

[PATCH] emacs-hello: Do not calculate the count of the messages in

[Daniel Schoepe]

On Mon, 16 Jan 2012 11:33:59 +, David Edmondson  wrote:
> Daniel, will you include this in your next version? (I'd like to mark it
> 'obsolete'.)

Yes, it sounds like a great improvement.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH v6 0/2] emacs: User-defined sections in notmuch-hello

[Daniel Schoepe]

On Mon, 16 Jan 2012 10:59:39 +, David Edmondson  wrote:
> Daniel, there was a bunch of feedback from Dmitry about the patch and a
> couple of other comments.
> 
> Do you plan to produce a new version?

Yes, I plan to do that (I know I already said that in December) and
already have a partially rebased version. I hope I will get to finish it
up and incorporate the suggestions from this thread soon.

Cheers,
Daniel

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: [PATCH v6 0/2] emacs: User-defined sections in notmuch-hello

[Daniel Schoepe]

On Mon, 16 Jan 2012 10:59:39 +, David Edmondson d...@dme.org wrote:
 Daniel, there was a bunch of feedback from Dmitry about the patch and a
 couple of other comments.
 
 Do you plan to produce a new version?

Yes, I plan to do that (I know I already said that in December) and
already have a partially rebased version. I hope I will get to finish it
up and incorporate the suggestions from this thread soon.

Cheers,
Daniel



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

Re: [PATCH] emacs-hello: Do not calculate the count of the messages in

[Daniel Schoepe]

On Mon, 16 Jan 2012 11:33:59 +, David Edmondson d...@dme.org wrote:
 Daniel, will you include this in your next version? (I'd like to mark it
 'obsolete'.)

Yes, it sounds like a great improvement.


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