Re: [PATCH] test: canonicalize content-type in "Sending a message via (fake) SMTP"
On Fri, Aug 31 2012, da...@tethera.net wrote: > From: David Bremner > > The version of message.el in emacs24 omits the charset=us-ascii, > causing the current version of this test to fail. With this patch, we > accept either option. According to RFC 2046, they are semantically > equivalent. > --- LGTM. Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test: use (format "%S") to print nil in emacs test.
On Fri, Aug 31 2012, Austin Clements wrote: > LGTM. Alternatively, the test could be > (null (notmuch-wash)) > with the correct answer being 't'. That would avoid the awkward > detour through a string, but either way is good as long as this test > passes. I was going to vote this (null ... thing) but as the function returns nil when no match found it is more obvious th compare for that instead of "t". And, there is not much of a detour for the expected value nil, outputted as "nil" (without quotes) :). So: LGTM. "Alternatively, the test could" use (prin1 (...)) directly, "but either way is good as long as this test passes." Tomi > > Quoth da...@tethera.net on Aug 30 at 10:09 pm: >> From: David Bremner >> >> The behaviour of "emacsclient --eval nil" changed from emacs23 to >> emacs24, and in emacs24 it prints 'nil' rather than an empty string. >> >> (format "%S" foo) produces a sexpr form of foo, and is consistent >> between the two versions. >> --- >> >> This fixes another test failure on emacs24. >> >> I guess maybe all test_emacs output could be canonicalized this way, >> but I suspect that would be pretty disruptive. >> >> test/emacs-subject-to-filename |6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/test/emacs-subject-to-filename b/test/emacs-subject-to-filename >> index 176e685..a0ffdfe 100755 >> --- a/test/emacs-subject-to-filename >> +++ b/test/emacs-subject-to-filename >> @@ -8,10 +8,10 @@ test_emacs '(ignore)' >> >> # test notmuch-wash-subject-to-patch-sequence-number (subject) >> test_begin_subtest "no patch sequence number" >> -output=$(test_emacs '(notmuch-wash-subject-to-patch-sequence-number >> - "[PATCH] A normal patch subject without numbers")' >> +output=$(test_emacs '(format "%S" >> (notmuch-wash-subject-to-patch-sequence-number >> + "[PATCH] A normal patch subject without numbers"))' >> ) >> -test_expect_equal "$output" "" >> +test_expect_equal "$output" '"nil"' >> >> test_begin_subtest "patch sequence number #1" >> output=$(test_emacs '(notmuch-wash-subject-to-patch-sequence-number > ___ > notmuch mailing list > notmuch@notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test: use (format "%S") to print nil in emacs test.
On Fri, Aug 31 2012, Tomi Ollila wrote: > On Fri, Aug 31 2012, Austin Clements wrote: > >> LGTM. Alternatively, the test could be >> (null (notmuch-wash)) >> with the correct answer being 't'. That would avoid the awkward >> detour through a string, but either way is good as long as this test >> passes. > > I was going to vote this (null ... thing) but as the function returns > nil when no match found it is more obvious th compare for that instead > of "t". > > And, there is not much of a detour for the expected value nil, outputted > as "nil" (without quotes) :). > > So: > > LGTM. "Alternatively, the test could" use (prin1 (...)) directly, > "but either way is good as long as this test passes." I withdraw this prin1 suggestion, as it doesn't seem to work with all emaces (if any, I thought I test this well enough). Probably the reason is that format returns string and prin1 prints it -- but when using emacsclient the prints (might) go to the buffer never seen...) So, unconditional LGTM :D > Tomi Tomi > >> >> Quoth da...@tethera.net on Aug 30 at 10:09 pm: >>> From: David Bremner >>> >>> The behaviour of "emacsclient --eval nil" changed from emacs23 to >>> emacs24, and in emacs24 it prints 'nil' rather than an empty string. >>> >>> (format "%S" foo) produces a sexpr form of foo, and is consistent >>> between the two versions. >>> --- >>> >>> This fixes another test failure on emacs24. >>> >>> I guess maybe all test_emacs output could be canonicalized this way, >>> but I suspect that would be pretty disruptive. >>> >>> test/emacs-subject-to-filename |6 +++--- >>> 1 file changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/test/emacs-subject-to-filename b/test/emacs-subject-to-filename >>> index 176e685..a0ffdfe 100755 >>> --- a/test/emacs-subject-to-filename >>> +++ b/test/emacs-subject-to-filename >>> @@ -8,10 +8,10 @@ test_emacs '(ignore)' >>> >>> # test notmuch-wash-subject-to-patch-sequence-number (subject) >>> test_begin_subtest "no patch sequence number" >>> -output=$(test_emacs '(notmuch-wash-subject-to-patch-sequence-number >>> - "[PATCH] A normal patch subject without numbers")' >>> +output=$(test_emacs '(format "%S" >>> (notmuch-wash-subject-to-patch-sequence-number >>> + "[PATCH] A normal patch subject without numbers"))' >>> ) >>> -test_expect_equal "$output" "" >>> +test_expect_equal "$output" '"nil"' >>> >>> test_begin_subtest "patch sequence number #1" >>> output=$(test_emacs '(notmuch-wash-subject-to-patch-sequence-number >> ___ >> notmuch mailing list >> notmuch@notmuchmail.org >> http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test: use (format "%S") to print nil in emacs test.
da...@tethera.net writes: > From: David Bremner > > The behaviour of "emacsclient --eval nil" changed from emacs23 to > emacs24, and in emacs24 it prints 'nil' rather than an empty string. pushed, d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test: canonicalize content-type in "Sending a message via (fake) SMTP"
da...@tethera.net writes: > From: David Bremner > > The version of message.el in emacs24 omits the charset=us-ascii, > causing the current version of this test to fail. With this patch, we > accept either option. According to RFC 2046, they are semantically > equivalent. Pushed the second one. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug (?) difference 24.1 and 23.3.1
On Fri, Aug 03 2012, Svend Sorensen wrote: > > I was also getting an error about gnus-inhibit-images when running emacs > 24. Adding (require 'gnus-art) to my emacs config fixed the problem. Where is your emacs24 from? From Debian sid? David has some gnus-inhibit-images related tests failing on his system and he is using emacs24 from debian sid. My gnus-inhibit-images related emacs24 tests don't fail (I've compiled emacs 24.1 & emacs 24.2 from source). Also buildbot at http://notmuch.hocat.ca/builders/master-emacs24/builds/173 have now successful build (we assume it uses emacs24 from gentoo -- until Tom verifies this). > > http://notmuchmail.org/pipermail/notmuch/2012/008405.html > > Svend Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug (?) difference 24.1 and 23.3.1
Tomi Ollila writes: > On Fri, Aug 03 2012, Svend Sorensen wrote: > >> >> I was also getting an error about gnus-inhibit-images when running emacs >> 24. Adding (require 'gnus-art) to my emacs config fixed the problem. > > Where is your emacs24 from? From Debian sid? I've been having the gnus-inhibit-images problem with emacs24 from Debian sid. (require 'guns-art) appears to have fixed it, and may also have fixed the more serious problem that the property notmuch-message-extent was not being set. Now I just have to get used to pictures in my email bergey ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] test: move all emacs show tests to emacs-show test script
Jameson Graef Rollins writes: > No functional change. > > Most notmuch-show mode tests were in the emacs script, while some were > in the emacs-show script. This moves all the notmuch-show mode tests > to the emacs-show script, to make things a little more consistent. This seems harmless enough, and independent of the the other patch in the series, but I broke it with one fixes for emacs24. Interested in rebasing it? d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
RE: S/MIME support
Jameson Graef Rollins writes: > > Ah, I didn't notice that: > > https://bugzilla.gnome.org/show_bug.cgi?id=674032 > > Encouragingly, it sounds like Jeffery is working on it. FYI it's marked fixed in upstream git now. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 05/11] lib: add ability to store recipients in message structure
Hi Jamie, continuing in the review from yesterday... On Mon, Aug 20 2012, Jameson Graef Rollins wrote: [...] > diff --git a/lib/notmuch-private.h b/lib/notmuch-private.h > index bfb4111..27a41b6 100644 > --- a/lib/notmuch-private.h > +++ b/lib/notmuch-private.h > @@ -325,6 +325,15 @@ notmuch_message_set_author (notmuch_message_t *message, > const char *author); > const char * > notmuch_message_get_author (notmuch_message_t *message); > > +/* Set the recipients of 'message' - this is the representation used > + * when displaying the message */ > +void > +notmuch_message_set_recipients (notmuch_message_t *message, const char > *recipients); > + > +/* Get the authors of 'message' */ s/authors/recipients > +const char * > +notmuch_message_get_recipients (notmuch_message_t *message); > + > > /* index.cc */ > > -- > 1.7.10.4 > > ___ > notmuch mailing list > notmuch@notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 06/11] lib: store thread recipients in thread structure
On Mon, Aug 20 2012, Jameson Graef Rollins wrote:
> This utilizes the new thread addresses struct to store thread
> recipients, again in parallel to authors.
>
> Since message recipients are not stored in the database, including
> recipients in the thread structure exacts a significant overhead as
> the recipients are retrieved from the original message files. Because
> of this, a new boolean argument, include_recipients, is added to the
> necessary functions (_notmuch_thread_create, _thread_add_message and
> _thread_add_matched_message) that controls whether the recipients are
> fetched and included. If message recipients are ever stored in the
> database this new argument could probably be removed.
> ---
> lib/notmuch-private.h |3 +-
> lib/notmuch.h | 14 +
> lib/query.cc |3 +-
> lib/thread.cc | 77
> +
> 4 files changed, 76 insertions(+), 21 deletions(-)
>
> diff --git a/lib/notmuch-private.h b/lib/notmuch-private.h
> index 27a41b6..32d1523 100644
> --- a/lib/notmuch-private.h
> +++ b/lib/notmuch-private.h
> @@ -232,7 +232,8 @@ _notmuch_thread_create (void *ctx,
> unsigned int seed_doc_id,
> notmuch_doc_id_set_t *match_set,
> notmuch_string_list_t *excluded_terms,
> - notmuch_sort_t sort);
> + notmuch_sort_t sort,
> + notmuch_bool_t include_recipients);
>
> /* message.cc */
>
> diff --git a/lib/notmuch.h b/lib/notmuch.h
> index 6acd38d..f9e71c1 100644
> --- a/lib/notmuch.h
> +++ b/lib/notmuch.h
> @@ -759,6 +759,20 @@ notmuch_thread_get_matched_messages (notmuch_thread_t
> *thread);
> const char *
> notmuch_thread_get_authors (notmuch_thread_t *thread);
>
> +/* Get the recipients of 'thread'
> + *
> + * The returned string is a comma-separated list of the names of the
> + * recipients of mail messages in the query results that belong to this
> + * thread.
> + *
> + * The returned string belongs to 'thread' and as such, should not be
> + * modified by the caller and will only be valid for as long as the
> + * thread is valid, (which is until notmuch_thread_destroy or until
> + * the query from which it derived is destroyed).
> + */
> +const char *
> +notmuch_thread_get_recipients (notmuch_thread_t *thread);
> +
> /* Get the subject of 'thread'
> *
> * The subject is taken from the first message (according to the query
> diff --git a/lib/query.cc b/lib/query.cc
> index e9c1a2d..54833a7 100644
> --- a/lib/query.cc
> +++ b/lib/query.cc
> @@ -486,7 +486,8 @@ notmuch_threads_get (notmuch_threads_t *threads)
> doc_id,
> &threads->match_set,
> threads->query->exclude_terms,
> -threads->query->sort);
> +threads->query->sort,
> +FALSE);
> }
>
> void
> diff --git a/lib/thread.cc b/lib/thread.cc
> index 757e143..baf07c2 100644
> --- a/lib/thread.cc
> +++ b/lib/thread.cc
> @@ -37,6 +37,7 @@ struct visible _notmuch_thread {
> char *thread_id;
> char *subject;
> notmuch_thread_addresses_t *authors;
> +notmuch_thread_addresses_t *recipients;
> GHashTable *tags;
>
> notmuch_message_list_t *message_list;
> @@ -63,6 +64,7 @@ static int
> _notmuch_thread_destructor (notmuch_thread_t *thread)
> {
> _notmuch_thread_addresses_destructor (thread->authors);
> +_notmuch_thread_addresses_destructor (thread->recipients);
> g_hash_table_unref (thread->tags);
> g_hash_table_unref (thread->message_hash);
> return 0;
> @@ -204,14 +206,17 @@ _thread_cleanup_address (notmuch_thread_t *thread,
> static void
> _thread_add_message (notmuch_thread_t *thread,
>notmuch_message_t *message,
> - notmuch_string_list_t *exclude_terms)
> + notmuch_string_list_t *exclude_terms,
> + notmuch_bool_t include_recipients)
> {
> notmuch_tags_t *tags;
> const char *tag;
> -InternetAddressList *list = NULL;
> +InternetAddressList *from_list = NULL;
> +InternetAddressList *to_list = NULL;
> InternetAddress *address;
> const char *from, *author;
> -char *clean_author;
> +const char *to, *recipient;
> +char *clean_address;
>
> _notmuch_message_list_add_message (thread->message_list,
> talloc_steal (thread, message));
> @@ -223,10 +228,9 @@ _thread_add_message (notmuch_thread_t *thread,
>
> from = notmuch_message_get_header (message, "from");
> if (from)
> - list = internet_address_list_parse_string (from);
> -
> -if (list) {
> - address = internet_address_list_get_address (list, 0);
> + from_list = internet_address_list_parse_string (from);
> +if (from_list) {
> + address = interne
Re: [PATCH 08/11] cli: add thread recipients to search output
On Mon, Aug 20 2012, Jameson Graef Rollins wrote: > This adds a "--include-recipients" option to notmuch search. With > structured output formats (e.g. json), a new recipients field will be > included that holds recipients of the thread. Matched and non-matched > recipients are delineated as with authors. > > As mentioned in the previous patch for the underlying lib functions, > the need for the option is because message recipients are not stored > in the database and therefore retrieving them adds a significant > overhead. If they were included, this option would not be necessary. > --- > lib/notmuch.h|6 +- > lib/query.cc |5 +++-- > notmuch-search.c | 14 +++--- > notmuch-show.c |2 +- > test/json|1 - > 5 files changed, 20 insertions(+), 8 deletions(-) > > diff --git a/lib/notmuch.h b/lib/notmuch.h > index f9e71c1..8eb455e 100644 > --- a/lib/notmuch.h > +++ b/lib/notmuch.h > @@ -642,6 +642,9 @@ notmuch_threads_valid (notmuch_threads_t *threads); > > /* Get the current thread from 'threads' as a notmuch_thread_t. > * > + * If the include_recipients flag is TRUE, thread recipients will be > + * included in the returned thread object. > + * > * Note: The returned thread belongs to 'threads' and has a lifetime > * identical to it (and the query to which it belongs). > * > @@ -652,7 +655,8 @@ notmuch_threads_valid (notmuch_threads_t *threads); > * NULL. > */ > notmuch_thread_t * > -notmuch_threads_get (notmuch_threads_t *threads); > +notmuch_threads_get (notmuch_threads_t *threads, > + notmuch_bool_t include_recipients); What about adding a new function notmuch_threds_get_with_recipients() to not break public API? It would also make the sources more readable. -M. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] test: show tests
Mark Walters writes: > --- > test/notmuch-test |1 + > test/show | 47 +++ > 2 files changed, 48 insertions(+), 0 deletions(-) > create mode 100755 test/show Hi Mark; This series was tagged stale at some point, but I imagine the conflict was trivial (since it mainly adds a new file). If you do decide to rebase it, how about some actual commit messages? Also, I wonder if you should use the new test_expect_equal_json function? d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 6/6] test: another test wrt ignoring user-specified files and directories
Pieter Praet writes: > Demonstrates that *every* file/directory which matches one of the values > in 'new.ignore' will be ignored, independent of its depth/location in > the mail store. > --- This test fails, apparently because it hard codes the test file paths. Otherwise the remainder of the series looks fine to me. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 11/11] lib: add recipients to database
On Mon, Aug 20 2012, Jameson Graef Rollins wrote:
> This adds just the "to" recipients, but probably "cc"s should be
> included as well.
> ---
> lib/database.cc |2 +-
> lib/message.cc|4
> lib/notmuch-private.h |2 ++
> 3 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/lib/database.cc b/lib/database.cc
> index 761dc1a..4c1d578 100644
> --- a/lib/database.cc
> +++ b/lib/database.cc
> @@ -1814,7 +1814,7 @@ notmuch_database_add_message (notmuch_database_t
> *notmuch,
> goto DONE;
>
> date = notmuch_message_file_get_header (message_file, "date");
> - _notmuch_message_set_header_values (message, date, from, subject);
> + _notmuch_message_set_header_values (message, date, from, to,
> subject);
>
> _notmuch_message_index_file (message, filename);
> } else {
> diff --git a/lib/message.cc b/lib/message.cc
> index fa28073..cc5c8a0 100644
> --- a/lib/message.cc
> +++ b/lib/message.cc
> @@ -420,6 +420,8 @@ notmuch_message_get_header (notmuch_message_t *message,
> const char *header)
> * available */
> if (strcasecmp (header, "from") == 0)
> value = message->doc.get_value (NOTMUCH_VALUE_FROM);
> +if (strcasecmp (header, "to") == 0)
> + value = message->doc.get_value (NOTMUCH_VALUE_TO);
> else if (strcasecmp (header, "subject") == 0)
> value = message->doc.get_value (NOTMUCH_VALUE_SUBJECT);
> else if (strcasecmp (header, "message-id") == 0)
> @@ -830,6 +832,7 @@ void
> _notmuch_message_set_header_values (notmuch_message_t *message,
> const char *date,
> const char *from,
> + const char *to,
> const char *subject)
> {
> time_t time_value;
> @@ -844,6 +847,7 @@ _notmuch_message_set_header_values (notmuch_message_t
> *message,
> message->doc.add_value (NOTMUCH_VALUE_TIMESTAMP,
> Xapian::sortable_serialise (time_value));
> message->doc.add_value (NOTMUCH_VALUE_FROM, from);
> +message->doc.add_value (NOTMUCH_VALUE_TO, to);
> message->doc.add_value (NOTMUCH_VALUE_SUBJECT, subject);
> }
>
> diff --git a/lib/notmuch-private.h b/lib/notmuch-private.h
> index 32d1523..f56c580 100644
> --- a/lib/notmuch-private.h
> +++ b/lib/notmuch-private.h
> @@ -95,6 +95,7 @@ typedef enum {
> NOTMUCH_VALUE_TIMESTAMP = 0,
> NOTMUCH_VALUE_MESSAGE_ID,
> NOTMUCH_VALUE_FROM,
> +NOTMUCH_VALUE_TO,
It would be definitely useful to add other headers to the database (and
make them searchable). As far as I remember this is on the todo list for
ages. I'm only not sure that the approach of adding every possible
header manually (like in this patch) is a good approach. Emails can
contain arbitrary headers so there would be always some header missing.
I'm not that much familiar with Xapian to figure out how to implement
this.
Otherwise this series looks quite well. I'm only not sure whether to
merge it now or after changing the storage of headers in the database.
Probably, if emacs interface is also extended to use this feature as
part of saved searches or hello-section in a way that I can see the list
of drafts on one click from hello screen. I'd vote for merging this now.
However, I've just looked how does my drafts folder (messages saved with
C-x C-s) looks like and one problem I see there is that draft messages
do not have message ids. Do you have an idea how to implement drafts in
emacs UI?
Thanks,
-Michal
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] test: canonicalize content-type in "Sending a message via (fake) SMTP"
On Fri, Aug 31 2012, david at tethera.net wrote: > From: David Bremner > > The version of message.el in emacs24 omits the charset=us-ascii, > causing the current version of this test to fail. With this patch, we > accept either option. According to RFC 2046, they are semantically > equivalent. > --- LGTM. Tomi
[PATCH] test: use (format "%S") to print nil in emacs test.
On Fri, Aug 31 2012, Austin Clements wrote: > LGTM. Alternatively, the test could be > (null (notmuch-wash)) > with the correct answer being 't'. That would avoid the awkward > detour through a string, but either way is good as long as this test > passes. I was going to vote this (null ... thing) but as the function returns nil when no match found it is more obvious th compare for that instead of "t". And, there is not much of a detour for the expected value nil, outputted as "nil" (without quotes) :). So: LGTM. "Alternatively, the test could" use (prin1 (...)) directly, "but either way is good as long as this test passes." Tomi > > Quoth david at tethera.net on Aug 30 at 10:09 pm: >> From: David Bremner >> >> The behaviour of "emacsclient --eval nil" changed from emacs23 to >> emacs24, and in emacs24 it prints 'nil' rather than an empty string. >> >> (format "%S" foo) produces a sexpr form of foo, and is consistent >> between the two versions. >> --- >> >> This fixes another test failure on emacs24. >> >> I guess maybe all test_emacs output could be canonicalized this way, >> but I suspect that would be pretty disruptive. >> >> test/emacs-subject-to-filename |6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/test/emacs-subject-to-filename b/test/emacs-subject-to-filename >> index 176e685..a0ffdfe 100755 >> --- a/test/emacs-subject-to-filename >> +++ b/test/emacs-subject-to-filename >> @@ -8,10 +8,10 @@ test_emacs '(ignore)' >> >> # test notmuch-wash-subject-to-patch-sequence-number (subject) >> test_begin_subtest "no patch sequence number" >> -output=$(test_emacs '(notmuch-wash-subject-to-patch-sequence-number >> - "[PATCH] A normal patch subject without numbers")' >> +output=$(test_emacs '(format "%S" >> (notmuch-wash-subject-to-patch-sequence-number >> + "[PATCH] A normal patch subject without numbers"))' >> ) >> -test_expect_equal "$output" "" >> +test_expect_equal "$output" '"nil"' >> >> test_begin_subtest "patch sequence number #1" >> output=$(test_emacs '(notmuch-wash-subject-to-patch-sequence-number > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] test: use (format "%S") to print nil in emacs test.
On Fri, Aug 31 2012, Tomi Ollila wrote: > On Fri, Aug 31 2012, Austin Clements wrote: > >> LGTM. Alternatively, the test could be >> (null (notmuch-wash)) >> with the correct answer being 't'. That would avoid the awkward >> detour through a string, but either way is good as long as this test >> passes. > > I was going to vote this (null ... thing) but as the function returns > nil when no match found it is more obvious th compare for that instead > of "t". > > And, there is not much of a detour for the expected value nil, outputted > as "nil" (without quotes) :). > > So: > > LGTM. "Alternatively, the test could" use (prin1 (...)) directly, > "but either way is good as long as this test passes." I withdraw this prin1 suggestion, as it doesn't seem to work with all emaces (if any, I thought I test this well enough). Probably the reason is that format returns string and prin1 prints it -- but when using emacsclient the prints (might) go to the buffer never seen...) So, unconditional LGTM :D > Tomi Tomi > >> >> Quoth david at tethera.net on Aug 30 at 10:09 pm: >>> From: David Bremner >>> >>> The behaviour of "emacsclient --eval nil" changed from emacs23 to >>> emacs24, and in emacs24 it prints 'nil' rather than an empty string. >>> >>> (format "%S" foo) produces a sexpr form of foo, and is consistent >>> between the two versions. >>> --- >>> >>> This fixes another test failure on emacs24. >>> >>> I guess maybe all test_emacs output could be canonicalized this way, >>> but I suspect that would be pretty disruptive. >>> >>> test/emacs-subject-to-filename |6 +++--- >>> 1 file changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/test/emacs-subject-to-filename b/test/emacs-subject-to-filename >>> index 176e685..a0ffdfe 100755 >>> --- a/test/emacs-subject-to-filename >>> +++ b/test/emacs-subject-to-filename >>> @@ -8,10 +8,10 @@ test_emacs '(ignore)' >>> >>> # test notmuch-wash-subject-to-patch-sequence-number (subject) >>> test_begin_subtest "no patch sequence number" >>> -output=$(test_emacs '(notmuch-wash-subject-to-patch-sequence-number >>> - "[PATCH] A normal patch subject without numbers")' >>> +output=$(test_emacs '(format "%S" >>> (notmuch-wash-subject-to-patch-sequence-number >>> + "[PATCH] A normal patch subject without numbers"))' >>> ) >>> -test_expect_equal "$output" "" >>> +test_expect_equal "$output" '"nil"' >>> >>> test_begin_subtest "patch sequence number #1" >>> output=$(test_emacs '(notmuch-wash-subject-to-patch-sequence-number >> ___ >> notmuch mailing list >> notmuch at notmuchmail.org >> http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] test: use (format "%S") to print nil in emacs test.
david at tethera.net writes: > From: David Bremner > > The behaviour of "emacsclient --eval nil" changed from emacs23 to > emacs24, and in emacs24 it prints 'nil' rather than an empty string. pushed, d
[PATCH] test: canonicalize content-type in "Sending a message via (fake) SMTP"
david at tethera.net writes: > From: David Bremner > > The version of message.el in emacs24 omits the charset=us-ascii, > causing the current version of this test to fail. With this patch, we > accept either option. According to RFC 2046, they are semantically > equivalent. Pushed the second one. d
Bug (?) difference 24.1 and 23.3.1
On Fri, Aug 03 2012, Svend Sorensen wrote: > > I was also getting an error about gnus-inhibit-images when running emacs > 24. Adding (require 'gnus-art) to my emacs config fixed the problem. Where is your emacs24 from? From Debian sid? David has some gnus-inhibit-images related tests failing on his system and he is using emacs24 from debian sid. My gnus-inhibit-images related emacs24 tests don't fail (I've compiled emacs 24.1 & emacs 24.2 from source). Also buildbot at http://notmuch.hocat.ca/builders/master-emacs24/builds/173 have now successful build (we assume it uses emacs24 from gentoo -- until Tom verifies this). > > http://notmuchmail.org/pipermail/notmuch/2012/008405.html > > Svend Tomi
Bug (?) difference 24.1 and 23.3.1
Tomi Ollila writes: > On Fri, Aug 03 2012, Svend Sorensen wrote: > >> >> I was also getting an error about gnus-inhibit-images when running emacs >> 24. Adding (require 'gnus-art) to my emacs config fixed the problem. > > Where is your emacs24 from? From Debian sid? I've been having the gnus-inhibit-images problem with emacs24 from Debian sid. (require 'guns-art) appears to have fixed it, and may also have fixed the more serious problem that the property notmuch-message-extent was not being set. Now I just have to get used to pictures in my email bergey
[PATCH 2/2] test: move all emacs show tests to emacs-show test script
Jameson Graef Rollins writes: > No functional change. > > Most notmuch-show mode tests were in the emacs script, while some were > in the emacs-show script. This moves all the notmuch-show mode tests > to the emacs-show script, to make things a little more consistent. This seems harmless enough, and independent of the the other patch in the series, but I broke it with one fixes for emacs24. Interested in rebasing it? d
S/MIME support
Jameson Graef Rollins writes: > > Ah, I didn't notice that: > > https://bugzilla.gnome.org/show_bug.cgi?id=674032 > > Encouragingly, it sounds like Jeffery is working on it. FYI it's marked fixed in upstream git now. d
[PATCH 05/11] lib: add ability to store recipients in message structure
Hi Jamie, continuing in the review from yesterday... On Mon, Aug 20 2012, Jameson Graef Rollins wrote: [...] > diff --git a/lib/notmuch-private.h b/lib/notmuch-private.h > index bfb4111..27a41b6 100644 > --- a/lib/notmuch-private.h > +++ b/lib/notmuch-private.h > @@ -325,6 +325,15 @@ notmuch_message_set_author (notmuch_message_t *message, > const char *author); > const char * > notmuch_message_get_author (notmuch_message_t *message); > > +/* Set the recipients of 'message' - this is the representation used > + * when displaying the message */ > +void > +notmuch_message_set_recipients (notmuch_message_t *message, const char > *recipients); > + > +/* Get the authors of 'message' */ s/authors/recipients > +const char * > +notmuch_message_get_recipients (notmuch_message_t *message); > + > > /* index.cc */ > > -- > 1.7.10.4 > > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 06/11] lib: store thread recipients in thread structure
On Mon, Aug 20 2012, Jameson Graef Rollins wrote:
> This utilizes the new thread addresses struct to store thread
> recipients, again in parallel to authors.
>
> Since message recipients are not stored in the database, including
> recipients in the thread structure exacts a significant overhead as
> the recipients are retrieved from the original message files. Because
> of this, a new boolean argument, include_recipients, is added to the
> necessary functions (_notmuch_thread_create, _thread_add_message and
> _thread_add_matched_message) that controls whether the recipients are
> fetched and included. If message recipients are ever stored in the
> database this new argument could probably be removed.
> ---
> lib/notmuch-private.h |3 +-
> lib/notmuch.h | 14 +
> lib/query.cc |3 +-
> lib/thread.cc | 77
> +
> 4 files changed, 76 insertions(+), 21 deletions(-)
>
> diff --git a/lib/notmuch-private.h b/lib/notmuch-private.h
> index 27a41b6..32d1523 100644
> --- a/lib/notmuch-private.h
> +++ b/lib/notmuch-private.h
> @@ -232,7 +232,8 @@ _notmuch_thread_create (void *ctx,
> unsigned int seed_doc_id,
> notmuch_doc_id_set_t *match_set,
> notmuch_string_list_t *excluded_terms,
> - notmuch_sort_t sort);
> + notmuch_sort_t sort,
> + notmuch_bool_t include_recipients);
>
> /* message.cc */
>
> diff --git a/lib/notmuch.h b/lib/notmuch.h
> index 6acd38d..f9e71c1 100644
> --- a/lib/notmuch.h
> +++ b/lib/notmuch.h
> @@ -759,6 +759,20 @@ notmuch_thread_get_matched_messages (notmuch_thread_t
> *thread);
> const char *
> notmuch_thread_get_authors (notmuch_thread_t *thread);
>
> +/* Get the recipients of 'thread'
> + *
> + * The returned string is a comma-separated list of the names of the
> + * recipients of mail messages in the query results that belong to this
> + * thread.
> + *
> + * The returned string belongs to 'thread' and as such, should not be
> + * modified by the caller and will only be valid for as long as the
> + * thread is valid, (which is until notmuch_thread_destroy or until
> + * the query from which it derived is destroyed).
> + */
> +const char *
> +notmuch_thread_get_recipients (notmuch_thread_t *thread);
> +
> /* Get the subject of 'thread'
> *
> * The subject is taken from the first message (according to the query
> diff --git a/lib/query.cc b/lib/query.cc
> index e9c1a2d..54833a7 100644
> --- a/lib/query.cc
> +++ b/lib/query.cc
> @@ -486,7 +486,8 @@ notmuch_threads_get (notmuch_threads_t *threads)
> doc_id,
> &threads->match_set,
> threads->query->exclude_terms,
> -threads->query->sort);
> +threads->query->sort,
> +FALSE);
> }
>
> void
> diff --git a/lib/thread.cc b/lib/thread.cc
> index 757e143..baf07c2 100644
> --- a/lib/thread.cc
> +++ b/lib/thread.cc
> @@ -37,6 +37,7 @@ struct visible _notmuch_thread {
> char *thread_id;
> char *subject;
> notmuch_thread_addresses_t *authors;
> +notmuch_thread_addresses_t *recipients;
> GHashTable *tags;
>
> notmuch_message_list_t *message_list;
> @@ -63,6 +64,7 @@ static int
> _notmuch_thread_destructor (notmuch_thread_t *thread)
> {
> _notmuch_thread_addresses_destructor (thread->authors);
> +_notmuch_thread_addresses_destructor (thread->recipients);
> g_hash_table_unref (thread->tags);
> g_hash_table_unref (thread->message_hash);
> return 0;
> @@ -204,14 +206,17 @@ _thread_cleanup_address (notmuch_thread_t *thread,
> static void
> _thread_add_message (notmuch_thread_t *thread,
>notmuch_message_t *message,
> - notmuch_string_list_t *exclude_terms)
> + notmuch_string_list_t *exclude_terms,
> + notmuch_bool_t include_recipients)
> {
> notmuch_tags_t *tags;
> const char *tag;
> -InternetAddressList *list = NULL;
> +InternetAddressList *from_list = NULL;
> +InternetAddressList *to_list = NULL;
> InternetAddress *address;
> const char *from, *author;
> -char *clean_author;
> +const char *to, *recipient;
> +char *clean_address;
>
> _notmuch_message_list_add_message (thread->message_list,
> talloc_steal (thread, message));
> @@ -223,10 +228,9 @@ _thread_add_message (notmuch_thread_t *thread,
>
> from = notmuch_message_get_header (message, "from");
> if (from)
> - list = internet_address_list_parse_string (from);
> -
> -if (list) {
> - address = internet_address_list_get_address (list, 0);
> + from_list = internet_address_list_parse_string (from);
> +if (from_list) {
> + address = interne
[PATCH 08/11] cli: add thread recipients to search output
On Mon, Aug 20 2012, Jameson Graef Rollins wrote: > This adds a "--include-recipients" option to notmuch search. With > structured output formats (e.g. json), a new recipients field will be > included that holds recipients of the thread. Matched and non-matched > recipients are delineated as with authors. > > As mentioned in the previous patch for the underlying lib functions, > the need for the option is because message recipients are not stored > in the database and therefore retrieving them adds a significant > overhead. If they were included, this option would not be necessary. > --- > lib/notmuch.h|6 +- > lib/query.cc |5 +++-- > notmuch-search.c | 14 +++--- > notmuch-show.c |2 +- > test/json|1 - > 5 files changed, 20 insertions(+), 8 deletions(-) > > diff --git a/lib/notmuch.h b/lib/notmuch.h > index f9e71c1..8eb455e 100644 > --- a/lib/notmuch.h > +++ b/lib/notmuch.h > @@ -642,6 +642,9 @@ notmuch_threads_valid (notmuch_threads_t *threads); > > /* Get the current thread from 'threads' as a notmuch_thread_t. > * > + * If the include_recipients flag is TRUE, thread recipients will be > + * included in the returned thread object. > + * > * Note: The returned thread belongs to 'threads' and has a lifetime > * identical to it (and the query to which it belongs). > * > @@ -652,7 +655,8 @@ notmuch_threads_valid (notmuch_threads_t *threads); > * NULL. > */ > notmuch_thread_t * > -notmuch_threads_get (notmuch_threads_t *threads); > +notmuch_threads_get (notmuch_threads_t *threads, > + notmuch_bool_t include_recipients); What about adding a new function notmuch_threds_get_with_recipients() to not break public API? It would also make the sources more readable. -M.
[PATCH 2/2] test: show tests
Mark Walters writes: > --- > test/notmuch-test |1 + > test/show | 47 +++ > 2 files changed, 48 insertions(+), 0 deletions(-) > create mode 100755 test/show Hi Mark; This series was tagged stale at some point, but I imagine the conflict was trivial (since it mainly adds a new file). If you do decide to rebase it, how about some actual commit messages? Also, I wonder if you should use the new test_expect_equal_json function? d
[PATCH 6/6] test: another test wrt ignoring user-specified files and directories
Pieter Praet writes: > Demonstrates that *every* file/directory which matches one of the values > in 'new.ignore' will be ignored, independent of its depth/location in > the mail store. > --- This test fails, apparently because it hard codes the test file paths. Otherwise the remainder of the series looks fine to me. d
[PATCH 11/11] lib: add recipients to database
On Mon, Aug 20 2012, Jameson Graef Rollins wrote:
> This adds just the "to" recipients, but probably "cc"s should be
> included as well.
> ---
> lib/database.cc |2 +-
> lib/message.cc|4
> lib/notmuch-private.h |2 ++
> 3 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/lib/database.cc b/lib/database.cc
> index 761dc1a..4c1d578 100644
> --- a/lib/database.cc
> +++ b/lib/database.cc
> @@ -1814,7 +1814,7 @@ notmuch_database_add_message (notmuch_database_t
> *notmuch,
> goto DONE;
>
> date = notmuch_message_file_get_header (message_file, "date");
> - _notmuch_message_set_header_values (message, date, from, subject);
> + _notmuch_message_set_header_values (message, date, from, to,
> subject);
>
> _notmuch_message_index_file (message, filename);
> } else {
> diff --git a/lib/message.cc b/lib/message.cc
> index fa28073..cc5c8a0 100644
> --- a/lib/message.cc
> +++ b/lib/message.cc
> @@ -420,6 +420,8 @@ notmuch_message_get_header (notmuch_message_t *message,
> const char *header)
> * available */
> if (strcasecmp (header, "from") == 0)
> value = message->doc.get_value (NOTMUCH_VALUE_FROM);
> +if (strcasecmp (header, "to") == 0)
> + value = message->doc.get_value (NOTMUCH_VALUE_TO);
> else if (strcasecmp (header, "subject") == 0)
> value = message->doc.get_value (NOTMUCH_VALUE_SUBJECT);
> else if (strcasecmp (header, "message-id") == 0)
> @@ -830,6 +832,7 @@ void
> _notmuch_message_set_header_values (notmuch_message_t *message,
> const char *date,
> const char *from,
> + const char *to,
> const char *subject)
> {
> time_t time_value;
> @@ -844,6 +847,7 @@ _notmuch_message_set_header_values (notmuch_message_t
> *message,
> message->doc.add_value (NOTMUCH_VALUE_TIMESTAMP,
> Xapian::sortable_serialise (time_value));
> message->doc.add_value (NOTMUCH_VALUE_FROM, from);
> +message->doc.add_value (NOTMUCH_VALUE_TO, to);
> message->doc.add_value (NOTMUCH_VALUE_SUBJECT, subject);
> }
>
> diff --git a/lib/notmuch-private.h b/lib/notmuch-private.h
> index 32d1523..f56c580 100644
> --- a/lib/notmuch-private.h
> +++ b/lib/notmuch-private.h
> @@ -95,6 +95,7 @@ typedef enum {
> NOTMUCH_VALUE_TIMESTAMP = 0,
> NOTMUCH_VALUE_MESSAGE_ID,
> NOTMUCH_VALUE_FROM,
> +NOTMUCH_VALUE_TO,
It would be definitely useful to add other headers to the database (and
make them searchable). As far as I remember this is on the todo list for
ages. I'm only not sure that the approach of adding every possible
header manually (like in this patch) is a good approach. Emails can
contain arbitrary headers so there would be always some header missing.
I'm not that much familiar with Xapian to figure out how to implement
this.
Otherwise this series looks quite well. I'm only not sure whether to
merge it now or after changing the storage of headers in the database.
Probably, if emacs interface is also extended to use this feature as
part of saved searches or hello-section in a way that I can see the list
of drafts on one click from hello screen. I'd vote for merging this now.
However, I've just looked how does my drafts folder (messages saved with
C-x C-s) looks like and one problem I see there is that draft messages
do not have message ids. Do you have an idea how to implement drafts in
emacs UI?
Thanks,
-Michal
