[PATCH] test: use `princ' instead of `message' calls in emacs tests
The patch replaces all (message (buffer-string)) calls in emacs
tests with (princ (buffer-string)). This avoids accidentally
interpreting '%' as format specifiers and makes code simpler
because we do not need to capture stderr.
Also, the patch works around an Emacs (23.3+1-1 on current Debian
Unstable) segfault in "Ensure that emacs doesn't drop results"
test. Note: the segfault does not happen on every test run.
Though, it seems to be consistently reproducible if the test uses
300 messages instead of 30. Hopefully, it is the crash described
in Emacs bug #8545 [1] which is already fixed.
[1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8545
---
The patch applies to the release-candidate/0.6 branch. This is a
rewrite of
id:"1305006007-26445-1-git-send-email-dmitry.kuroch...@gmail.com"
following Austin's suggestion.
Regards,
Dmitry
test/emacs | 18 +-
test/emacs-large-search-buffer |5 +++--
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/test/emacs b/test/emacs
index b376033..2e85b0c 100755
--- a/test/emacs
+++ b/test/emacs
@@ -7,38 +7,38 @@ EXPECTED=../emacs.expected-output
add_email_corpus
test_begin_subtest "Basic notmuch-hello view in emacs"
-output=$(test_emacs '(notmuch-hello) (message (buffer-string))' 2>&1)
+output=$(test_emacs '(notmuch-hello) (princ (buffer-string))')
expected=$(cat $EXPECTED/notmuch-hello)
test_expect_equal "$output" "$expected"
test_begin_subtest "Saved search with 0 results"
-output=$(test_emacs '(setq notmuch-show-empty-saved-searches t) (setq
notmuch-saved-searches '\''(("inbox" . "tag:inbox") ("unread" . "tag:unread")
("empty" . "tag:doesnotexist"))) (notmuch-hello) (message (buffer-string))'
2>&1)
+output=$(test_emacs '(setq notmuch-show-empty-saved-searches t) (setq
notmuch-saved-searches '\''(("inbox" . "tag:inbox") ("unread" . "tag:unread")
("empty" . "tag:doesnotexist"))) (notmuch-hello) (princ (buffer-string))')
expected=$(cat $EXPECTED/notmuch-hello-with-empty)
test_expect_equal "$output" "$expected"
test_begin_subtest "No saved searches displayed (all with 0 results)"
-output=$(test_emacs '(setq notmuch-saved-searches '\''(("empty" .
"tag:doesnotexist"))) (notmuch-hello) (message (buffer-string))' 2>&1)
+output=$(test_emacs '(setq notmuch-saved-searches '\''(("empty" .
"tag:doesnotexist"))) (notmuch-hello) (princ (buffer-string))')
expected=$(cat $EXPECTED/notmuch-hello-no-saved-searches)
test_expect_equal "$output" "$expected"
test_begin_subtest "Basic notmuch-search view in emacs"
-output=$(test_emacs '(notmuch-search "tag:inbox") (notmuch-test-wait) (message
(buffer-string))' 2>&1)
+output=$(test_emacs '(notmuch-search "tag:inbox") (notmuch-test-wait) (princ
(buffer-string))')
expected=$(cat $EXPECTED/notmuch-search-tag-inbox)
test_expect_equal "$output" "$expected"
test_begin_subtest "Navigation of notmuch-hello to search results"
-output=$(test_emacs '(notmuch-hello) (goto-char (point-min))
(re-search-forward "inbox") (widget-button-press (point)) (notmuch-test-wait)
(message (buffer-string))' 2>&1)
+output=$(test_emacs '(notmuch-hello) (goto-char (point-min))
(re-search-forward "inbox") (widget-button-press (point)) (notmuch-test-wait)
(princ (buffer-string))')
expected=$(cat $EXPECTED/notmuch-hello-view-inbox)
test_expect_equal "$output" "$expected"
test_begin_subtest "Basic notmuch-show view in emacs"
maildir_storage_thread=$(notmuch search --output=threads
id:20091117190054.gu3...@dottiness.seas.harvard.edu)
-output=$(test_emacs "(notmuch-show \"$maildir_storage_thread\") (message
(buffer-string))" 2>&1)
+output=$(test_emacs "(notmuch-show \"$maildir_storage_thread\") (princ
(buffer-string))")
expected=$(cat $EXPECTED/notmuch-show-thread-maildir-storage)
test_expect_equal "$output" "$expected"
test_begin_subtest "Navigation of notmuch-search to thread view"
-output=$(test_emacs '(notmuch-search "tag:inbox") (notmuch-test-wait)
(goto-char (point-min)) (re-search-forward "Working with Maildir")
(notmuch-search-show-thread) (notmuch-test-wait) (message (buffer-string))'
2>&1)
+output=$(test_emacs '(notmuch-search "tag:inbox") (notmuch-test-wait)
(goto-char (point-min)) (re-search-forward "Working with Maildir")
(notmuch-search-show-thread) (notmuch-test-wait) (princ (buffer-string))')
test_expect_equal "$output" "$expected"
test_begin_subtest "Add tag from search view"
@@ -102,7 +102,7 @@ test_expect_equal "$output" "thread:XXX 1974-03-29 [1/1]
Notmuch Test Suite; T
test_begin_subtest "Reply within emacs"
# We sed away everything before the ^From in the output to avoid getting
# confused by messages such as "Parsing /home/cworth/.mailrc... done"
-output=$(test_emacs '(notmuch-search "subject:\"testing message sent via
SMTP\"") (notmuch-test-wait) (notmuch-search-reply-to-thread) (message
(buffer-string))' 2>&1 | sed -ne '/^From/,$ p' | sed -e 's/^In-Reply-To:
<.*>$/In-Reply-To: /')
+output=$(test_emacs '(notmuch-search "su
Re: [PATCH] test: add "%s" format string to all `message' calls in emacs tests
On Tue, 10 May 2011 01:47:17 -0400, Austin Clements wrote:
> This looks good to me (and is certainly more correct), but seems
> rather roundabout. Is there a reason this code doesn't simply (princ
> (buffer-string))?
>
Thanks, Austin!
I am, unfortunately, not an Emacs Lisp expert. I did not know about
princ, so I improved what we had :) Princ seems to work fine. And
certainly looks cleaner than using message and capturing stderr. It
also fixes the segfault.
I will send another patch that uses princ instead of message.
Regards,
Dmitry
> On Tue, May 10, 2011 at 1:40 AM, Dmitry Kurochkin
> wrote:
> > The patch replaces all (message (buffer-string)) calls in emacs
> > tests with (message "%s" (buffer-string)). This works around an
> > Emacs (23.3+1-1 on current Debian Unstable) segfault in "Ensure
> > that emacs doesn't drop results" test. Note: the segfault does
> > not happen on every test run. Though, it seems to be
> > consistently reproducible if the test uses 300 messages instead
> > of 30. Hopefully, it is the crash described in Emacs bug #8545
> > [1] which is already fixed.
> >
> > Also, the patch makes the code more correct - we want to avoid
> > accidentally interpreting '%' as format specifiers.
> >
> > [1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8545
> > ---
> >
> > The patch applies to the release-candidate/0.6 branch.
> >
> > Regards,
> > Dmitry
> >
> >
> > test/emacs | 18 +-
> > test/emacs-large-search-buffer | 5 +++--
> > 2 files changed, 12 insertions(+), 11 deletions(-)
> >
> > diff --git a/test/emacs b/test/emacs
> > index b376033..5b39423 100755
> > --- a/test/emacs
> > +++ b/test/emacs
> > @@ -7,38 +7,38 @@ EXPECTED=../emacs.expected-output
> > add_email_corpus
> >
> > test_begin_subtest "Basic notmuch-hello view in emacs"
> > -output=$(test_emacs '(notmuch-hello) (message (buffer-string))' 2>&1)
> > +output=$(test_emacs '(notmuch-hello) (message "%s" (buffer-string))' 2>&1)
> > expected=$(cat $EXPECTED/notmuch-hello)
> > test_expect_equal "$output" "$expected"
> >
> > test_begin_subtest "Saved search with 0 results"
> > -output=$(test_emacs '(setq notmuch-show-empty-saved-searches t) (setq
> > notmuch-saved-searches '\''(("inbox" . "tag:inbox") ("unread" .
> > "tag:unread") ("empty" . "tag:doesnotexist"))) (notmuch-hello) (message
> > (buffer-string))' 2>&1)
> > +output=$(test_emacs '(setq notmuch-show-empty-saved-searches t) (setq
> > notmuch-saved-searches '\''(("inbox" . "tag:inbox") ("unread" .
> > "tag:unread") ("empty" . "tag:doesnotexist"))) (notmuch-hello) (message
> > "%s" (buffer-string))' 2>&1)
> > expected=$(cat $EXPECTED/notmuch-hello-with-empty)
> > test_expect_equal "$output" "$expected"
> >
> > test_begin_subtest "No saved searches displayed (all with 0 results)"
> > -output=$(test_emacs '(setq notmuch-saved-searches '\''(("empty" .
> > "tag:doesnotexist"))) (notmuch-hello) (message (buffer-string))' 2>&1)
> > +output=$(test_emacs '(setq notmuch-saved-searches '\''(("empty" .
> > "tag:doesnotexist"))) (notmuch-hello) (message "%s" (buffer-string))' 2>&1)
> > expected=$(cat $EXPECTED/notmuch-hello-no-saved-searches)
> > test_expect_equal "$output" "$expected"
> >
> > test_begin_subtest "Basic notmuch-search view in emacs"
> > -output=$(test_emacs '(notmuch-search "tag:inbox") (notmuch-test-wait)
> > (message (buffer-string))' 2>&1)
> > +output=$(test_emacs '(notmuch-search "tag:inbox") (notmuch-test-wait)
> > (message "%s" (buffer-string))' 2>&1)
> > expected=$(cat $EXPECTED/notmuch-search-tag-inbox)
> > test_expect_equal "$output" "$expected"
> >
> > test_begin_subtest "Navigation of notmuch-hello to search results"
> > -output=$(test_emacs '(notmuch-hello) (goto-char (point-min))
> > (re-search-forward "inbox") (widget-button-press (point))
> > (notmuch-test-wait) (message (buffer-string))' 2>&1)
> > +output=$(test_emacs '(notmuch-hello) (goto-char (point-min))
> > (re-search-forward "inbox") (widget-button-press (point))
> > (notmuch-test-wait) (message "%s" (buffer-string))' 2>&1)
> > expected=$(cat $EXPECTED/notmuch-hello-view-inbox)
> > test_expect_equal "$output" "$expected"
> >
> > test_begin_subtest "Basic notmuch-show view in emacs"
> > maildir_storage_thread=$(notmuch search --output=threads
> > id:20091117190054.gu3...@dottiness.seas.harvard.edu)
> > -output=$(test_emacs "(notmuch-show \"$maildir_storage_thread\") (message
> > (buffer-string))" 2>&1)
> > +output=$(test_emacs "(notmuch-show \"$maildir_storage_thread\") (message
> > \"%s\" (buffer-string))" 2>&1)
> > expected=$(cat $EXPECTED/notmuch-show-thread-maildir-storage)
> > test_expect_equal "$output" "$expected"
> >
> > test_begin_subtest "Navigation of notmuch-search to thread view"
> > -output=$(test_emacs '(notmuch-search "tag:inbox") (notmuch-test-wait)
> > (goto-char (point-min)) (re-search-forward "Working with Maildir")
> > (notmuch-search-show-thread) (notmuch-test-wait) (message (buffer-st
Re: [PATCH] test: add "%s" format string to all `message' calls in emacs tests
This looks good to me (and is certainly more correct), but seems
rather roundabout. Is there a reason this code doesn't simply (princ
(buffer-string))?
On Tue, May 10, 2011 at 1:40 AM, Dmitry Kurochkin
wrote:
> The patch replaces all (message (buffer-string)) calls in emacs
> tests with (message "%s" (buffer-string)). This works around an
> Emacs (23.3+1-1 on current Debian Unstable) segfault in "Ensure
> that emacs doesn't drop results" test. Note: the segfault does
> not happen on every test run. Though, it seems to be
> consistently reproducible if the test uses 300 messages instead
> of 30. Hopefully, it is the crash described in Emacs bug #8545
> [1] which is already fixed.
>
> Also, the patch makes the code more correct - we want to avoid
> accidentally interpreting '%' as format specifiers.
>
> [1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8545
> ---
>
> The patch applies to the release-candidate/0.6 branch.
>
> Regards,
> Dmitry
>
>
> test/emacs | 18 +-
> test/emacs-large-search-buffer | 5 +++--
> 2 files changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/test/emacs b/test/emacs
> index b376033..5b39423 100755
> --- a/test/emacs
> +++ b/test/emacs
> @@ -7,38 +7,38 @@ EXPECTED=../emacs.expected-output
> add_email_corpus
>
> test_begin_subtest "Basic notmuch-hello view in emacs"
> -output=$(test_emacs '(notmuch-hello) (message (buffer-string))' 2>&1)
> +output=$(test_emacs '(notmuch-hello) (message "%s" (buffer-string))' 2>&1)
> expected=$(cat $EXPECTED/notmuch-hello)
> test_expect_equal "$output" "$expected"
>
> test_begin_subtest "Saved search with 0 results"
> -output=$(test_emacs '(setq notmuch-show-empty-saved-searches t) (setq
> notmuch-saved-searches '\''(("inbox" . "tag:inbox") ("unread" . "tag:unread")
> ("empty" . "tag:doesnotexist"))) (notmuch-hello) (message (buffer-string))'
> 2>&1)
> +output=$(test_emacs '(setq notmuch-show-empty-saved-searches t) (setq
> notmuch-saved-searches '\''(("inbox" . "tag:inbox") ("unread" . "tag:unread")
> ("empty" . "tag:doesnotexist"))) (notmuch-hello) (message "%s"
> (buffer-string))' 2>&1)
> expected=$(cat $EXPECTED/notmuch-hello-with-empty)
> test_expect_equal "$output" "$expected"
>
> test_begin_subtest "No saved searches displayed (all with 0 results)"
> -output=$(test_emacs '(setq notmuch-saved-searches '\''(("empty" .
> "tag:doesnotexist"))) (notmuch-hello) (message (buffer-string))' 2>&1)
> +output=$(test_emacs '(setq notmuch-saved-searches '\''(("empty" .
> "tag:doesnotexist"))) (notmuch-hello) (message "%s" (buffer-string))' 2>&1)
> expected=$(cat $EXPECTED/notmuch-hello-no-saved-searches)
> test_expect_equal "$output" "$expected"
>
> test_begin_subtest "Basic notmuch-search view in emacs"
> -output=$(test_emacs '(notmuch-search "tag:inbox") (notmuch-test-wait)
> (message (buffer-string))' 2>&1)
> +output=$(test_emacs '(notmuch-search "tag:inbox") (notmuch-test-wait)
> (message "%s" (buffer-string))' 2>&1)
> expected=$(cat $EXPECTED/notmuch-search-tag-inbox)
> test_expect_equal "$output" "$expected"
>
> test_begin_subtest "Navigation of notmuch-hello to search results"
> -output=$(test_emacs '(notmuch-hello) (goto-char (point-min))
> (re-search-forward "inbox") (widget-button-press (point)) (notmuch-test-wait)
> (message (buffer-string))' 2>&1)
> +output=$(test_emacs '(notmuch-hello) (goto-char (point-min))
> (re-search-forward "inbox") (widget-button-press (point)) (notmuch-test-wait)
> (message "%s" (buffer-string))' 2>&1)
> expected=$(cat $EXPECTED/notmuch-hello-view-inbox)
> test_expect_equal "$output" "$expected"
>
> test_begin_subtest "Basic notmuch-show view in emacs"
> maildir_storage_thread=$(notmuch search --output=threads
> id:20091117190054.gu3...@dottiness.seas.harvard.edu)
> -output=$(test_emacs "(notmuch-show \"$maildir_storage_thread\") (message
> (buffer-string))" 2>&1)
> +output=$(test_emacs "(notmuch-show \"$maildir_storage_thread\") (message
> \"%s\" (buffer-string))" 2>&1)
> expected=$(cat $EXPECTED/notmuch-show-thread-maildir-storage)
> test_expect_equal "$output" "$expected"
>
> test_begin_subtest "Navigation of notmuch-search to thread view"
> -output=$(test_emacs '(notmuch-search "tag:inbox") (notmuch-test-wait)
> (goto-char (point-min)) (re-search-forward "Working with Maildir")
> (notmuch-search-show-thread) (notmuch-test-wait) (message (buffer-string))'
> 2>&1)
> +output=$(test_emacs '(notmuch-search "tag:inbox") (notmuch-test-wait)
> (goto-char (point-min)) (re-search-forward "Working with Maildir")
> (notmuch-search-show-thread) (notmuch-test-wait) (message "%s"
> (buffer-string))' 2>&1)
> test_expect_equal "$output" "$expected"
>
> test_begin_subtest "Add tag from search view"
> @@ -102,7 +102,7 @@ test_expect_equal "$output" "thread:XXX 1974-03-29
> [1/1] Notmuch Test Suite; T
> test_begin_subtest "Reply within emacs"
> # We sed away everything before the ^From in the output to avoid getting
> # confus
[PATCH] test: add "%s" format string to all `message' calls in emacs tests
The patch replaces all (message (buffer-string)) calls in emacs
tests with (message "%s" (buffer-string)). This works around an
Emacs (23.3+1-1 on current Debian Unstable) segfault in "Ensure
that emacs doesn't drop results" test. Note: the segfault does
not happen on every test run. Though, it seems to be
consistently reproducible if the test uses 300 messages instead
of 30. Hopefully, it is the crash described in Emacs bug #8545
[1] which is already fixed.
Also, the patch makes the code more correct - we want to avoid
accidentally interpreting '%' as format specifiers.
[1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8545
---
The patch applies to the release-candidate/0.6 branch.
Regards,
Dmitry
test/emacs | 18 +-
test/emacs-large-search-buffer |5 +++--
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/test/emacs b/test/emacs
index b376033..5b39423 100755
--- a/test/emacs
+++ b/test/emacs
@@ -7,38 +7,38 @@ EXPECTED=../emacs.expected-output
add_email_corpus
test_begin_subtest "Basic notmuch-hello view in emacs"
-output=$(test_emacs '(notmuch-hello) (message (buffer-string))' 2>&1)
+output=$(test_emacs '(notmuch-hello) (message "%s" (buffer-string))' 2>&1)
expected=$(cat $EXPECTED/notmuch-hello)
test_expect_equal "$output" "$expected"
test_begin_subtest "Saved search with 0 results"
-output=$(test_emacs '(setq notmuch-show-empty-saved-searches t) (setq
notmuch-saved-searches '\''(("inbox" . "tag:inbox") ("unread" . "tag:unread")
("empty" . "tag:doesnotexist"))) (notmuch-hello) (message (buffer-string))'
2>&1)
+output=$(test_emacs '(setq notmuch-show-empty-saved-searches t) (setq
notmuch-saved-searches '\''(("inbox" . "tag:inbox") ("unread" . "tag:unread")
("empty" . "tag:doesnotexist"))) (notmuch-hello) (message "%s"
(buffer-string))' 2>&1)
expected=$(cat $EXPECTED/notmuch-hello-with-empty)
test_expect_equal "$output" "$expected"
test_begin_subtest "No saved searches displayed (all with 0 results)"
-output=$(test_emacs '(setq notmuch-saved-searches '\''(("empty" .
"tag:doesnotexist"))) (notmuch-hello) (message (buffer-string))' 2>&1)
+output=$(test_emacs '(setq notmuch-saved-searches '\''(("empty" .
"tag:doesnotexist"))) (notmuch-hello) (message "%s" (buffer-string))' 2>&1)
expected=$(cat $EXPECTED/notmuch-hello-no-saved-searches)
test_expect_equal "$output" "$expected"
test_begin_subtest "Basic notmuch-search view in emacs"
-output=$(test_emacs '(notmuch-search "tag:inbox") (notmuch-test-wait) (message
(buffer-string))' 2>&1)
+output=$(test_emacs '(notmuch-search "tag:inbox") (notmuch-test-wait) (message
"%s" (buffer-string))' 2>&1)
expected=$(cat $EXPECTED/notmuch-search-tag-inbox)
test_expect_equal "$output" "$expected"
test_begin_subtest "Navigation of notmuch-hello to search results"
-output=$(test_emacs '(notmuch-hello) (goto-char (point-min))
(re-search-forward "inbox") (widget-button-press (point)) (notmuch-test-wait)
(message (buffer-string))' 2>&1)
+output=$(test_emacs '(notmuch-hello) (goto-char (point-min))
(re-search-forward "inbox") (widget-button-press (point)) (notmuch-test-wait)
(message "%s" (buffer-string))' 2>&1)
expected=$(cat $EXPECTED/notmuch-hello-view-inbox)
test_expect_equal "$output" "$expected"
test_begin_subtest "Basic notmuch-show view in emacs"
maildir_storage_thread=$(notmuch search --output=threads
id:20091117190054.gu3...@dottiness.seas.harvard.edu)
-output=$(test_emacs "(notmuch-show \"$maildir_storage_thread\") (message
(buffer-string))" 2>&1)
+output=$(test_emacs "(notmuch-show \"$maildir_storage_thread\") (message
\"%s\" (buffer-string))" 2>&1)
expected=$(cat $EXPECTED/notmuch-show-thread-maildir-storage)
test_expect_equal "$output" "$expected"
test_begin_subtest "Navigation of notmuch-search to thread view"
-output=$(test_emacs '(notmuch-search "tag:inbox") (notmuch-test-wait)
(goto-char (point-min)) (re-search-forward "Working with Maildir")
(notmuch-search-show-thread) (notmuch-test-wait) (message (buffer-string))'
2>&1)
+output=$(test_emacs '(notmuch-search "tag:inbox") (notmuch-test-wait)
(goto-char (point-min)) (re-search-forward "Working with Maildir")
(notmuch-search-show-thread) (notmuch-test-wait) (message "%s"
(buffer-string))' 2>&1)
test_expect_equal "$output" "$expected"
test_begin_subtest "Add tag from search view"
@@ -102,7 +102,7 @@ test_expect_equal "$output" "thread:XXX 1974-03-29 [1/1]
Notmuch Test Suite; T
test_begin_subtest "Reply within emacs"
# We sed away everything before the ^From in the output to avoid getting
# confused by messages such as "Parsing /home/cworth/.mailrc... done"
-output=$(test_emacs '(notmuch-search "subject:\"testing message sent via
SMTP\"") (notmuch-test-wait) (notmuch-search-reply-to-thread) (message
(buffer-string))' 2>&1 | sed -ne '/^From/,$ p' | sed -e 's/^In-Reply-To:
<.*>$/In-Reply-To: /')
+output=$(test_emacs '(notmuch-search "subject:\"testing message sent via
SMTP\"") (not
[PATCH] python/thread: always return a string in get_subject/authors
On 05/09/2011 09:00 PM, Sebastian Spaeth wrote: > On Mon, 09 May 2011 09:20:41 -0300, David Bremner > wrote: >> On Mon, 9 May 2011 09:06:34 +0200, Anton Khirnov >> wrote: >>> Now None is returned when those don't exist, which is inconvenient to >>> deal with. >> >> I'm not using the python bindings, but from a philosophical point of >> view, this change makes me a bit uncomfortable since it apparently >> merges two cases together, and makes an error (no Subject) >> indistinguishable from an odd situation (Subject of empty string). >> Or am I missing something here? > > This change makes me a bit uncomfortable too. 3 Reasons: > > - I believe users should be able to distinguish the case when someone > uses an empty subject, and when someone doesn't specify a subject at > all. I'm going to "me too!" this sentiment as well. Please do *not* conflate no-subject with subject-is-empty-string. If we leave them distinct, the caller is free to conflate them if they want. But if we conflate the two states first, there's no way for the caller to differentiate between the two if they want to. Thanks, --dkg -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110509/6eaa6210/attachment.pgp>
[PATCH 2/2] test: add test for saving attachments using notmuch-show-save-part
Use .gz filenames for saved attachments in the tests to check that Emacs does not re-compress the file. Use test_expect_equal_file instead of test_expect_equal to avoid binary output on the console. --- test/emacs | 14 +- 1 files changed, 9 insertions(+), 5 deletions(-) diff --git a/test/emacs b/test/emacs index 75dec89..b376033 100755 --- a/test/emacs +++ b/test/emacs @@ -112,11 +112,15 @@ Fcc: $(pwd)/mail/sent On Fri, 29 Mar 1974 10:00:00 -, Notmuch Test Suite wrote: > This is a test that messages are sent via SMTP" -test_begin_subtest "Save attachment from within emacs" -echo "./attachment" | test_emacs '(notmuch-show "id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com") (notmuch-show-save-attachments)' > /dev/null 2>&1 -output=$(cat attachment) -expected=$(cat $EXPECTED/attachment) -test_expect_equal "$output" "$expected" +test_begin_subtest "Save attachment from within emacs using notmuch-show-save-attachments" +# save as archive to test that Emacs does not re-compress .gz +echo ./attachment1.gz | test_emacs '(notmuch-show "id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com") (notmuch-show-save-attachments)' > /dev/null 2>&1 +test_expect_equal_file "$EXPECTED/attachment" attachment1.gz + +test_begin_subtest "Save attachment from within emacs using notmuch-show-save-part" +# save as archive to test that Emacs does not re-compress .gz +echo ./attachment2.gz | test_emacs '(notmuch-show-save-part "id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com" 5)' > /dev/null 2>&1 +test_expect_equal_file "$EXPECTED/attachment" attachment2.gz test_begin_subtest "View raw message within emacs" expected=$(cat $EXPECTED/raw-message-cf0c4d-52ad0a) -- 1.7.5.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/2] test: copy files in test_expect_equal_file instead of moving them
Before the change, test_expect_equal_file moved files it compared in case of failure. The patch changes it to copy the files instead. This allows testing non-temporary files which are stored in git. Note: the change should not result in new temporary files left after the tests. Test_expect_equal_file used to move files only on failure, so callers had to cleanup them anyway. --- test/test-lib.sh |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/test/test-lib.sh b/test/test-lib.sh index eaf5051..7cc43cd 100755 --- a/test/test-lib.sh +++ b/test/test-lib.sh @@ -477,8 +477,8 @@ test_expect_equal_file () test_ok_ "$test_subtest_name" else testname=$this_test.$test_count - mv "$output" $testname.output - mv "$expected" $testname.expected + cp "$output" $testname.output + cp "$expected" $testname.expected test_failure_ "$test_subtest_name" "$(diff -u $testname.expected $testname.output)" fi fi -- 1.7.5.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 0/2] test: add test for saving attachments using notmuch-show-save-part
This is amended patch from id:"1304990689-10933-1-git-send-email-dmitry.kuroch...@gmail.com" to test saving attachments withing Emacs using notmuch-show-save-part. It uses test_expect_equal_file instead of test_expect_equal as suggested by Jameson. This patch is for the release-candidate/0.6 branch. Regards, Dmitry ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Fix old style notmuch-fcc-dirs configuration check.
In notmuch 0.5 notmuch-fcc-dirs style changed. The previous code did not correctly identify an old configuration and, as a consequence, broke new configurations. The fix was extracted from a bigger patch series by David Edmondson id:"1290682750-30283-2-git-send-email-dme at dme.org". --- The patch is for the release-candidate/0.6 branch. Regards, Dmitry emacs/notmuch-maildir-fcc.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el index aede753..b6c6e2a 100644 --- a/emacs/notmuch-maildir-fcc.el +++ b/emacs/notmuch-maildir-fcc.el @@ -88,7 +88,7 @@ will NOT be removed or replaced." notmuch-fcc-dirs) ((and (listp notmuch-fcc-dirs) - (= 1 (length (car notmuch-fcc-dirs + (stringp (car notmuch-fcc-dirs))) ;; Old style - no longer works. (error "Invalid `notmuch-fcc-dirs' setting (old style)")) -- 1.7.5.1
[PATCH] test: saving attachments from within emacs using notmuch-show-save-part
--- Oops, the previos patch (id:"1304990327-8665-1-git-send-email-dmitry.kuroch...@gmail.com") has wrong title. s/notmuch-show-save-attachments/notmuch-show-save-part/ Regards, Dmitry test/emacs | 14 +++--- 1 files changed, 11 insertions(+), 3 deletions(-) diff --git a/test/emacs b/test/emacs index 75dec89..675a887 100755 --- a/test/emacs +++ b/test/emacs @@ -112,9 +112,17 @@ Fcc: $(pwd)/mail/sent On Fri, 29 Mar 1974 10:00:00 -, Notmuch Test Suite wrote: > This is a test that messages are sent via SMTP" -test_begin_subtest "Save attachment from within emacs" -echo "./attachment" | test_emacs '(notmuch-show "id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com") (notmuch-show-save-attachments)' > /dev/null 2>&1 -output=$(cat attachment) +test_begin_subtest "Save attachment from within emacs using notmuch-show-save-attachments" +# save as archive to test that Emacs does not re-compress .gz +echo "./attachment1.gz" | test_emacs '(notmuch-show "id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com") (notmuch-show-save-attachments)' > /dev/null 2>&1 +output=$(cat attachment1.gz) +expected=$(cat $EXPECTED/attachment) +test_expect_equal "$output" "$expected" + +test_begin_subtest "Save attachment from within emacs using notmuch-show-save-part" +# save as archive to test that Emacs does not re-compress .gz +echo "./attachment2.gz" | test_emacs '(notmuch-show-save-part "id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com" 5)' > /dev/null 2>&1 +output=$(cat attachment2.gz) expected=$(cat $EXPECTED/attachment) test_expect_equal "$output" "$expected" -- 1.7.5.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] python/thread: always return a string in get_subject/authors
On 05/09/2011 09:00 PM, Sebastian Spaeth wrote: > On Mon, 09 May 2011 09:20:41 -0300, David Bremner wrote: >> On Mon, 9 May 2011 09:06:34 +0200, Anton Khirnov wrote: >>> Now None is returned when those don't exist, which is inconvenient to >>> deal with. >> >> I'm not using the python bindings, but from a philosophical point of >> view, this change makes me a bit uncomfortable since it apparently >> merges two cases together, and makes an error (no Subject) >> indistinguishable from an odd situation (Subject of empty string). >> Or am I missing something here? > > This change makes me a bit uncomfortable too. 3 Reasons: > > - I believe users should be able to distinguish the case when someone > uses an empty subject, and when someone doesn't specify a subject at > all. I'm going to "me too!" this sentiment as well. Please do *not* conflate no-subject with subject-is-empty-string. If we leave them distinct, the caller is free to conflate them if they want. But if we conflate the two states first, there's no way for the caller to differentiate between the two if they want to. Thanks, --dkg signature.asc Description: OpenPGP digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] test: saving attachments from within emacs using notmuch-show-save-attachments
--- test/emacs | 14 +++--- 1 files changed, 11 insertions(+), 3 deletions(-) diff --git a/test/emacs b/test/emacs index 75dec89..675a887 100755 --- a/test/emacs +++ b/test/emacs @@ -112,9 +112,17 @@ Fcc: $(pwd)/mail/sent On Fri, 29 Mar 1974 10:00:00 -, Notmuch Test Suite wrote: > This is a test that messages are sent via SMTP" -test_begin_subtest "Save attachment from within emacs" -echo "./attachment" | test_emacs '(notmuch-show "id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com") (notmuch-show-save-attachments)' > /dev/null 2>&1 -output=$(cat attachment) +test_begin_subtest "Save attachment from within emacs using notmuch-show-save-attachments" +# save as archive to test that Emacs does not re-compress .gz +echo "./attachment1.gz" | test_emacs '(notmuch-show "id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com") (notmuch-show-save-attachments)' > /dev/null 2>&1 +output=$(cat attachment1.gz) +expected=$(cat $EXPECTED/attachment) +test_expect_equal "$output" "$expected" + +test_begin_subtest "Save attachment from within emacs using notmuch-show-save-part" +# save as archive to test that Emacs does not re-compress .gz +echo "./attachment2.gz" | test_emacs '(notmuch-show-save-part "id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com" 5)' > /dev/null 2>&1 +output=$(cat attachment2.gz) expected=$(cat $EXPECTED/attachment) test_expect_equal "$output" "$expected" -- 1.7.5.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] python/thread: always return a string in get_subject/authors
On Mon, 09 May 2011 09:20:41 -0300, David Bremner wrote: > On Mon, 9 May 2011 09:06:34 +0200, Anton Khirnov wrote: > > Now None is returned when those don't exist, which is inconvenient to > > deal with. > > I'm not using the python bindings, but from a philosophical point of > view, this change makes me a bit uncomfortable since it apparently > merges two cases together, and makes an error (no Subject) > indistinguishable from an odd situation (Subject of empty string). > Or am I missing something here? Hi there, This change makes me a bit uncomfortable too. 3 Reasons: - I believe users should be able to distinguish the case when someone uses an empty subject, and when someone doesn't specify a subject at all. - People have been writing code and breaking backwards compatability for such a small gain doesn't really seem worth it. - Testing-wise this is easy. Just test for "if subject:" on the returned value and you'll get both cases (empty and non-existing). But if people really want it, I won't object. Sebastian pgpuI8l9AZmPD.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] lib/message-file: plug three memleaks.
---
lib/message-file.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/lib/message-file.c b/lib/message-file.c
index 7722832..99505c1 100644
--- a/lib/message-file.c
+++ b/lib/message-file.c
@@ -341,12 +341,17 @@ notmuch_message_file_get_header (notmuch_message_file_t
*message,
strncpy(combined_header,header_sofar,hdrsofar);
*(combined_header+hdrsofar) = ' ';
strncpy(combined_header+hdrsofar+1,decoded_value,newhdr+1);
+ free (decoded_value);
g_hash_table_insert (message->headers, header, combined_header);
}
} else {
if (header_sofar == NULL) {
/* Only insert if we don't have a value for this header, yet. */
g_hash_table_insert (message->headers, header, decoded_value);
+ } else {
+ free (header);
+ free (decoded_value);
+ decoded_value = header_sofar;
}
}
/* if we found a match we can bail - unless of course we are
--
1.7.5.1
[PATCH] python/thread: always return a string in get_subject/authors
On Mon, 09 May 2011 09:20:41 -0300, David Bremner wrote: > On Mon, 9 May 2011 09:06:34 +0200, Anton Khirnov > wrote: > > Now None is returned when those don't exist, which is inconvenient to > > deal with. > > I'm not using the python bindings, but from a philosophical point of > view, this change makes me a bit uncomfortable since it apparently > merges two cases together, and makes an error (no Subject) > indistinguishable from an odd situation (Subject of empty string). > Or am I missing something here? The question is whether this is really a problem. For a single message, it might make sense to distinguish between 'no header' and 'empty header'. But those aren't message headers, those are thread properties. And I'd argue that a thread always has authors and a subject (possibly empty). -- Anton Khirnov
[PATCH] Don't re-compress .gz & al. in notmuch-show-save-part.
Write-region handles some file names specially, see Emacs Lisp manual section 25.11 Making Certain File Names "Magic" [1]. This is a nice feature for normal text editing, but it is not desirable if we need to save raw file content (e.g. attachment). In particular, this affects archives and may result in corrupted attachments saved with notmuch-show-save-part (attachment button click handler). Turns out, smart GNUS folks encountered the same problem and implemented write-region wrapper which inhibits some file name handlers. In particular, this wrapper is used in mm-save-part, which is why notmuch-save-attachments that uses it works fine with archives. The patch replaces write-region with mm-write-region in notmuch-show-save-part. Also it removes coding-system-for-write and require-final-newline setting in notmuch-show-save-part. The former is set in mm-write-region. The latter seems to be unneeded because mm-save-part does not use it. [1] http://www.gnu.org/s/emacs/manual/html_node/elisp/Magic-File-Names.html --- This patch is for the release-candidate/0.6 branch. I know Jameson has declared it ready for release, but perhaps it is not too late for a small fix? Adding a test for this would be nice, but is a low priority for me. If anyone volunteers, that would be welcomed :) Regards, Dmitry emacs/notmuch-show.el |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 825988c..23291ce 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -306,10 +306,11 @@ message at DEPTH in the current thread." "Filename to save as: " (or mailcap-download-directory "~/") nil nil - filename)) - (require-final-newline nil) - (coding-system-for-write 'no-conversion)) - (write-region (point-min) (point-max) file) + filename))) + ;; Don't re-compress .gz & al. Arguably we should make + ;; `file-name-handler-alist' nil, but that would chop + ;; ange-ftp, which is reasonable to use here. + (mm-write-region (point-min) (point-max) file nil nil nil 'no-conversion t) (defun notmuch-show-mm-display-part-inline (msg part content-type content) "Use the mm-decode/mm-view functions to display a part in the -- 1.7.5.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Use message-field-value instead of message-fetch-field in FCC header setup.
For message-fetch-field the buffer is expected to be narrowed to just the header of the message. That is not the case when notmuch-fcc-header-setup is run, hence a wrong header value may be returned. E.g. when forwarding an email, (message-fetch-field "From") returns the From header value of the forwarded email. Message-field-value is the same as message-fetch-field, only narrows the buffer to the headers first. --- The patch is for the release-candidate/0.6 branch. It is an amended version of a patch I sent a while ago id:"1278000507-22290-4-git-send-email-dmitry.kurochkin at gmail.com". Regards, Dmitry emacs/notmuch-maildir-fcc.el |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el index 3f1c124..aede753 100644 --- a/emacs/notmuch-maildir-fcc.el +++ b/emacs/notmuch-maildir-fcc.el @@ -80,7 +80,7 @@ will NOT be removed or replaced." (let ((subdir (cond ((or (not notmuch-fcc-dirs) - (message-fetch-field "Fcc")) + (message-field-value "Fcc")) ;; Nothing set or an existing header. nil) @@ -93,7 +93,7 @@ will NOT be removed or replaced." (error "Invalid `notmuch-fcc-dirs' setting (old style)")) ((listp notmuch-fcc-dirs) - (let* ((from (message-fetch-field "From")) + (let* ((from (message-field-value "From")) (match (catch 'first-match (dolist (re-folder notmuch-fcc-dirs) @@ -118,7 +118,7 @@ will NOT be removed or replaced." (concat (notmuch-database-path) "/" subdir) ;; finally test if fcc points to a valid maildir - (let ((fcc-header (message-fetch-field "Fcc"))) + (let ((fcc-header (message-field-value "Fcc"))) (unless (notmuch-maildir-fcc-dir-is-maildir-p fcc-header) (cond ((not (file-writable-p fcc-header)) (error (format "No permission to create %s, which does not exist" -- 1.7.5.1
Re: vim support improvements for 0.6
On Fri, May 6, 2011 at 10:51 PM, Jameson Graef Rollins wrote: > Hi, Filipe. I notice that you have been submitting a lot of patches for > vim support. As you may have seen, I'm trying to put together a release > candidate for notmuch 0.6. Since I know nothing about vim, would you be > willing to prepare a patch set that includes all of the patches to vim > support that you would like to see in the 0.6 release? > > I think the easiest way to do that would be for you to push a branch to > your public repo that includes all of the vim improvements rebased on > top of my release-candidate/0.6 branch. If you can then point me to > that branch, I can merge it with my release-candidate/0.6 branch and > push it out for others to test. > > Let me know what you think. All right. Hopefully nobody will request further changes to these patches: git://github.com/felipec/notmuch.git [fc-vim-next] It's not rebased on top of your branch, but there are no merge conflicts. Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
release-candidate/0.6
On Sun, 08 May 2011 17:57:48 -0700, Jameson Graef Rollins wrote: > On Fri, 06 May 2011 19:56:30 -0400, James Vasile > wrote: > > I sent two patches to the list on March 16. They were a bug fix to > > allow notmuch to correctly handle some poorly formatted email. Nobody > > ever replied, but I'd like to see the bug fixed nonetheless, as it > > results in unreadable mail. Since I've actually seen such mail in the > > wild, I'd like to see Notmuch handle it. > > Hey, James. Florian Friesdorf sent in a patch to sanitize the output of > notmuch search, which I think is the issue that you're patches were also > dealing with. Florian's patch has be pushed to my > release-candidate/0.6. Can you see if your issue is fixed there? If > not maybe you could try submitting a new patch that would apply to the > release-candidate/0.6 head. > > Thanks. I'll take a look at it this week. Thanks much.
[PATCH] python/thread: always return a string in get_subject/authors
On Mon, 09 May 2011 11:23:16 -0400, Jesse Rosenthal wrote: > The RFC says yes on the author, no on the subject. The only things > guaranteed are "From:" and originating timestamp. So I'm not sure why > subject should be guaranteed a string result and not, say, "Cc." Apologies -- I realize now you were talking about threads and not messages, so I can't defer to RFCs. I still agree with the others, and about how python users would deal with it. But I see your point better now. Sorry to clutter.
[PATCH] python/thread: always return a string in get_subject/authors
On Mon, 09 May 2011 17:13:10 +0200, Anton Khirnov wrote: > But those aren't message headers, those are thread properties. And I'd > argue that a thread always has authors and a subject (possibly empty). The RFC says yes on the author, no on the subject. The only things guaranteed are "From:" and originating timestamp. So I'm not sure why subject should be guaranteed a string result and not, say, "Cc." My sense is that Python users are prety good with testing against None, especially since (not "") == (not []) == (not None) == True. This change seems like it would end up producing more inconsistencies with the way you deal with headers, by producing special cases. --Jesse
release-candidate/0.6
On Fri, 06 May 2011 12:46:34 -0700, Jameson Graef Rollins wrote: > > I might try to add a couple of more things before declaring the > candidate release-ready, but this is more-or-less it. Please start > using this branch "in production" as much as possible, so that we can > build up a chorus of support for pushing this release out. Once you > have build, tested, and started using the branch, please reply to this > email thread to express your support for it's release. I've been using this branch now for a couple of days and its solid, thanks for pulling this together Mr. Rollins. > The release-candidate/0.6 branch also includes debian package updates, > so you should be able to easily build debian packages from the branch: > > git buildpackage -uc -us --git-ignore-branch I used this mechanism to build a package and install it, it worked well. I also ran lintian on it just to see if there were any issues, but you get an A+. micah -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110509/a99fc56d/attachment.pgp>
Re: release-candidate/0.6
Hi, folks. I have pushed a couple of more patches to release-candidate/0.6 [0]: * Dmitry's fix for emacs fcc * Anton Khirnov's memleak fixes I think that everything else can wait for later releases. ***I hereby declare that release-candidate/0.6 is ready for release.*** I think the only remaining release tasks would be to update the NEWS file, and then possibly debian/changelog if we want to expand the 0.6 entries a bit. Carl: what do you think? Are you willing to push this out as a new release? Please let me know if there's anything else I/we can do to facilitate that. Thanks! jamie. [0] git://finestructure.net/notmuch release-candidate/0.6 (commit id: 31b65daf40dbb5fd98a875452674fe6d1e5368db) pgpcOqsSsvVSz.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
release-candidate/0.6
Hi, folks. I have pushed a couple of more patches to release-candidate/0.6 [0]: * Dmitry's fix for emacs fcc * Anton Khirnov's memleak fixes I think that everything else can wait for later releases. ***I hereby declare that release-candidate/0.6 is ready for release.*** I think the only remaining release tasks would be to update the NEWS file, and then possibly debian/changelog if we want to expand the 0.6 entries a bit. Carl: what do you think? Are you willing to push this out as a new release? Please let me know if there's anything else I/we can do to facilitate that. Thanks! jamie. [0] git://finestructure.net/notmuch release-candidate/0.6 (commit id: 31b65daf40dbb5fd98a875452674fe6d1e5368db) -- 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/20110509/e2a6e77d/attachment.pgp>
Re: [PATCH] lib/message-file: plug three memleaks.
Hey, Anton. Thanks for identifying and fixing these. I've pushed this to the r-c/0.6 branch. jamie. pgpAdvniISBRY.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] lib/message-file: plug three memleaks.
Hey, Anton. Thanks for identifying and fixing these. I've pushed this to the r-c/0.6 branch. jamie. -- 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/20110509/cd5f561d/attachment.pgp>
Re: release-candidate/0.6
On Sun, 08 May 2011 17:57:48 -0700, Jameson Graef Rollins wrote: > On Fri, 06 May 2011 19:56:30 -0400, James Vasile > wrote: > > I sent two patches to the list on March 16. They were a bug fix to > > allow notmuch to correctly handle some poorly formatted email. Nobody > > ever replied, but I'd like to see the bug fixed nonetheless, as it > > results in unreadable mail. Since I've actually seen such mail in the > > wild, I'd like to see Notmuch handle it. > > Hey, James. Florian Friesdorf sent in a patch to sanitize the output of > notmuch search, which I think is the issue that you're patches were also > dealing with. Florian's patch has be pushed to my > release-candidate/0.6. Can you see if your issue is fixed there? If > not maybe you could try submitting a new patch that would apply to the > release-candidate/0.6 head. > > Thanks. I'll take a look at it this week. Thanks much. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Use message-field-value instead of message-fetch-field in FCC header setup.
On Mon, 9 May 2011 16:06:20 +0400, Dmitry Kurochkin wrote: > For message-fetch-field the buffer is expected to be narrowed to > just the header of the message. That is not the case when > notmuch-fcc-header-setup is run, hence a wrong header value may be > returned. E.g. when forwarding an > email, (message-fetch-field "From") returns the From header value > of the forwarded email. > > Message-field-value is the same as message-fetch-field, only > narrows the buffer to the headers first. Hey, Dmitry. This is a nice clean fix. I've applied it to the r-c/0.6. jamie. pgpiR7bLfmpMi.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Fix old style notmuch-fcc-dirs configuration check.
On Mon, 9 May 2011 20:04:54 +0400, Dmitry Kurochkin wrote: > In notmuch 0.5 notmuch-fcc-dirs style changed. The previous code > did not correctly identify an old configuration and, as a > consequence, broke new configurations. > > The fix was extracted from a bigger patch series by David > Edmondson id:"1290682750-30283-2-git-send-email-...@dme.org". Thanks for extracting the needed fix, Dmitry. This makes things much easier. Applied to r-c/0.6 jamie. pgp1qnuyYuuWv.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Use message-field-value instead of message-fetch-field in FCC header setup.
On Mon, 9 May 2011 16:06:20 +0400, Dmitry Kurochkin wrote: > For message-fetch-field the buffer is expected to be narrowed to > just the header of the message. That is not the case when > notmuch-fcc-header-setup is run, hence a wrong header value may be > returned. E.g. when forwarding an > email, (message-fetch-field "From") returns the From header value > of the forwarded email. > > Message-field-value is the same as message-fetch-field, only > narrows the buffer to the headers first. Hey, Dmitry. This is a nice clean fix. I've applied it to the r-c/0.6. jamie. -- 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/20110509/f0a2268a/attachment.pgp>
[PATCH] Fix old style notmuch-fcc-dirs configuration check.
On Mon, 9 May 2011 20:04:54 +0400, Dmitry Kurochkin wrote: > In notmuch 0.5 notmuch-fcc-dirs style changed. The previous code > did not correctly identify an old configuration and, as a > consequence, broke new configurations. > > The fix was extracted from a bigger patch series by David > Edmondson id:"1290682750-30283-2-git-send-email-dme at dme.org". Thanks for extracting the needed fix, Dmitry. This makes things much easier. Applied to r-c/0.6 jamie. -- 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/20110509/7e361d49/attachment.pgp>
[PATCH] python/thread: always return a string in get_subject/authors
On Mon, 9 May 2011 09:06:34 +0200, Anton Khirnov wrote: > Now None is returned when those don't exist, which is inconvenient to > deal with. I'm not using the python bindings, but from a philosophical point of view, this change makes me a bit uncomfortable since it apparently merges two cases together, and makes an error (no Subject) indistinguishable from an odd situation (Subject of empty string). Or am I missing something here? All the best, David
[PATCH] python/thread: always return a string in get_subject/authors
Now None is returned when those don't exist, which is inconvenient to deal with. --- bindings/python/notmuch/thread.py |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/bindings/python/notmuch/thread.py b/bindings/python/notmuch/thread.py index eebd6cb..cf26957 100644 --- a/bindings/python/notmuch/thread.py +++ b/bindings/python/notmuch/thread.py @@ -281,7 +281,8 @@ class Thread(object): """ if self._thread is None: raise NotmuchError(STATUS.NOT_INITIALIZED) -return Thread._get_authors(self._thread) +ret = Thread._get_authors(self._thread) +return ret if ret else '' def get_subject(self): """Returns the Subject of 'thread' @@ -291,7 +292,8 @@ class Thread(object): """ if self._thread is None: raise NotmuchError(STATUS.NOT_INITIALIZED) -return Thread._get_subject(self._thread) +ret = Thread._get_subject(self._thread) +return ret if ret else '' def get_newest_date(self): """Returns time_t of the newest message date -- 1.7.4.4
[PATCH] Fix old style notmuch-fcc-dirs configuration check.
In notmuch 0.5 notmuch-fcc-dirs style changed. The previous code did not correctly identify an old configuration and, as a consequence, broke new configurations. The fix was extracted from a bigger patch series by David Edmondson id:"1290682750-30283-2-git-send-email-...@dme.org". --- The patch is for the release-candidate/0.6 branch. Regards, Dmitry emacs/notmuch-maildir-fcc.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el index aede753..b6c6e2a 100644 --- a/emacs/notmuch-maildir-fcc.el +++ b/emacs/notmuch-maildir-fcc.el @@ -88,7 +88,7 @@ will NOT be removed or replaced." notmuch-fcc-dirs) ((and (listp notmuch-fcc-dirs) - (= 1 (length (car notmuch-fcc-dirs + (stringp (car notmuch-fcc-dirs))) ;; Old style - no longer works. (error "Invalid `notmuch-fcc-dirs' setting (old style)")) -- 1.7.5.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] python/thread: always return a string in get_subject/authors
On 9 May 2011 08:20, David Bremner wrote: > On Mon, ?9 May 2011 09:06:34 +0200, Anton Khirnov > wrote: >> Now None is returned when those don't exist, which is inconvenient to >> deal with. > > I'm not using the python bindings, but from a philosophical point of > view, this change makes me a bit uncomfortable since it apparently > merges two cases together, and makes an error (no Subject) > indistinguishable from an odd situation (Subject of empty string). > Or am I missing something here? I see the the same issue. Servilio
[PATCH] lib/message-file: plug three memleaks.
On Fri, 15 Apr 2011 16:43:58 +0200, Anton Khirnov wrote:
> ---
> lib/message-file.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/lib/message-file.c b/lib/message-file.c
> index 7722832..b7b3286 100644
> --- a/lib/message-file.c
> +++ b/lib/message-file.c
> @@ -341,12 +341,17 @@ notmuch_message_file_get_header (notmuch_message_file_t
> *message,
> strncpy(combined_header,header_sofar,hdrsofar);
> *(combined_header+hdrsofar) = ' ';
> strncpy(combined_header+hdrsofar+1,decoded_value,newhdr+1);
> + free(decoded_value);
> g_hash_table_insert (message->headers, header, combined_header);
> }
> } else {
> if (header_sofar == NULL) {
> /* Only insert if we don't have a value for this header, yet. */
> g_hash_table_insert (message->headers, header, decoded_value);
> + } else {
> + free(header);
> + free(decoded_value);
> + decoded_value = header_sofar;
> }
> }
> /* if we found a match we can bail - unless of course we are
> --
> 1.7.4.1
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
ping
--
Anton Khirnov
[PATCH] lib/message-file: plug three memleaks.
Cool. This looks like a pretty nasty leak and I'm pretty sure your
patch is correct (though it took me a while to convince myself!).
My one nit is code style. There should be a space between the
function name and the paren. (Oddly, the is_received handling that
you changed is the only place in notmuch where I've seen this style
violated; but there's no sense in spreading this inconsistency.)
On Mon, May 9, 2011 at 2:46 AM, Anton Khirnov wrote:
> On Fri, 15 Apr 2011 16:43:58 +0200, Anton Khirnov
> wrote:
>> ---
>> ?lib/message-file.c | ? ?5 +
>> ?1 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/lib/message-file.c b/lib/message-file.c
>> index 7722832..b7b3286 100644
>> --- a/lib/message-file.c
>> +++ b/lib/message-file.c
>> @@ -341,12 +341,17 @@ notmuch_message_file_get_header
>> (notmuch_message_file_t *message,
>> ? ? ? ? ? ? ? strncpy(combined_header,header_sofar,hdrsofar);
>> ? ? ? ? ? ? ? *(combined_header+hdrsofar) = ' ';
>> ? ? ? ? ? ? ? strncpy(combined_header+hdrsofar+1,decoded_value,newhdr+1);
>> + ? ? ? ? ? ? free(decoded_value);
>> ? ? ? ? ? ? ? g_hash_table_insert (message->headers, header,
>> combined_header);
>> ? ? ? ? ? }
>> ? ? ? } else {
>> ? ? ? ? ? if (header_sofar == NULL) {
>> ? ? ? ? ? ? ? /* Only insert if we don't have a value for this header, yet.
>> */
>> ? ? ? ? ? ? ? g_hash_table_insert (message->headers, header, decoded_value);
>> + ? ? ? ? } else {
>> + ? ? ? ? ? ? free(header);
>> + ? ? ? ? ? ? free(decoded_value);
>> + ? ? ? ? ? ? decoded_value = header_sofar;
>> ? ? ? ? ? }
>> ? ? ? }
>> ? ? ? /* if we found a match we can bail - unless of course we are
>> --
>> 1.7.4.1
>>
>> ___
>> notmuch mailing list
>> notmuch at notmuchmail.org
>> http://notmuchmail.org/mailman/listinfo/notmuch
>
> ping
>
> --
> Anton Khirnov
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>
Re: [PATCH] python/thread: always return a string in get_subject/authors
On Mon, 09 May 2011 11:23:16 -0400, Jesse Rosenthal wrote: > The RFC says yes on the author, no on the subject. The only things > guaranteed are "From:" and originating timestamp. So I'm not sure why > subject should be guaranteed a string result and not, say, "Cc." Apologies -- I realize now you were talking about threads and not messages, so I can't defer to RFCs. I still agree with the others, and about how python users would deal with it. But I see your point better now. Sorry to clutter. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] python/thread: always return a string in get_subject/authors
On Mon, 09 May 2011 17:13:10 +0200, Anton Khirnov wrote: > But those aren't message headers, those are thread properties. And I'd > argue that a thread always has authors and a subject (possibly empty). The RFC says yes on the author, no on the subject. The only things guaranteed are "From:" and originating timestamp. So I'm not sure why subject should be guaranteed a string result and not, say, "Cc." My sense is that Python users are prety good with testing against None, especially since (not "") == (not []) == (not None) == True. This change seems like it would end up producing more inconsistencies with the way you deal with headers, by producing special cases. --Jesse ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] lib/message-file: plug three memleaks.
---
lib/message-file.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/lib/message-file.c b/lib/message-file.c
index 7722832..99505c1 100644
--- a/lib/message-file.c
+++ b/lib/message-file.c
@@ -341,12 +341,17 @@ notmuch_message_file_get_header (notmuch_message_file_t
*message,
strncpy(combined_header,header_sofar,hdrsofar);
*(combined_header+hdrsofar) = ' ';
strncpy(combined_header+hdrsofar+1,decoded_value,newhdr+1);
+ free (decoded_value);
g_hash_table_insert (message->headers, header, combined_header);
}
} else {
if (header_sofar == NULL) {
/* Only insert if we don't have a value for this header, yet. */
g_hash_table_insert (message->headers, header, decoded_value);
+ } else {
+ free (header);
+ free (decoded_value);
+ decoded_value = header_sofar;
}
}
/* if we found a match we can bail - unless of course we are
--
1.7.5.1
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] python/thread: always return a string in get_subject/authors
On Mon, 09 May 2011 09:20:41 -0300, David Bremner wrote: > On Mon, 9 May 2011 09:06:34 +0200, Anton Khirnov wrote: > > Now None is returned when those don't exist, which is inconvenient to > > deal with. > > I'm not using the python bindings, but from a philosophical point of > view, this change makes me a bit uncomfortable since it apparently > merges two cases together, and makes an error (no Subject) > indistinguishable from an odd situation (Subject of empty string). > Or am I missing something here? The question is whether this is really a problem. For a single message, it might make sense to distinguish between 'no header' and 'empty header'. But those aren't message headers, those are thread properties. And I'd argue that a thread always has authors and a subject (possibly empty). -- Anton Khirnov ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] python/thread: always return a string in get_subject/authors
Your commit message is inconsistent with your change; is your intent to return None or the empty string? Also, could you modify your commit message to say what "those" are? On May 9, 2011 3:06 AM, "Anton Khirnov" wrote: -- next part -- An HTML attachment was scrubbed... URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110509/c70fe8b1/attachment.html>
Re: release-candidate/0.6
On Fri, 06 May 2011 12:46:34 -0700, Jameson Graef Rollins wrote: > > I might try to add a couple of more things before declaring the > candidate release-ready, but this is more-or-less it. Please start > using this branch "in production" as much as possible, so that we can > build up a chorus of support for pushing this release out. Once you > have build, tested, and started using the branch, please reply to this > email thread to express your support for it's release. I've been using this branch now for a couple of days and its solid, thanks for pulling this together Mr. Rollins. > The release-candidate/0.6 branch also includes debian package updates, > so you should be able to easily build debian packages from the branch: > > git buildpackage -uc -us --git-ignore-branch I used this mechanism to build a package and install it, it worked well. I also ran lintian on it just to see if there were any issues, but you get an A+. micah pgp79r76nep6I.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] python/thread: always return a string in get_subject/authors
On 9 May 2011 08:20, David Bremner wrote: > On Mon, 9 May 2011 09:06:34 +0200, Anton Khirnov wrote: >> Now None is returned when those don't exist, which is inconvenient to >> deal with. > > I'm not using the python bindings, but from a philosophical point of > view, this change makes me a bit uncomfortable since it apparently > merges two cases together, and makes an error (no Subject) > indistinguishable from an odd situation (Subject of empty string). > Or am I missing something here? I see the the same issue. Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] lib/message-file: plug three memleaks.
Cool. This looks like a pretty nasty leak and I'm pretty sure your
patch is correct (though it took me a while to convince myself!).
My one nit is code style. There should be a space between the
function name and the paren. (Oddly, the is_received handling that
you changed is the only place in notmuch where I've seen this style
violated; but there's no sense in spreading this inconsistency.)
On Mon, May 9, 2011 at 2:46 AM, Anton Khirnov wrote:
> On Fri, 15 Apr 2011 16:43:58 +0200, Anton Khirnov wrote:
>> ---
>> lib/message-file.c | 5 +
>> 1 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/lib/message-file.c b/lib/message-file.c
>> index 7722832..b7b3286 100644
>> --- a/lib/message-file.c
>> +++ b/lib/message-file.c
>> @@ -341,12 +341,17 @@ notmuch_message_file_get_header
>> (notmuch_message_file_t *message,
>> strncpy(combined_header,header_sofar,hdrsofar);
>> *(combined_header+hdrsofar) = ' ';
>> strncpy(combined_header+hdrsofar+1,decoded_value,newhdr+1);
>> + free(decoded_value);
>> g_hash_table_insert (message->headers, header,
>> combined_header);
>> }
>> } else {
>> if (header_sofar == NULL) {
>> /* Only insert if we don't have a value for this header, yet.
>> */
>> g_hash_table_insert (message->headers, header, decoded_value);
>> + } else {
>> + free(header);
>> + free(decoded_value);
>> + decoded_value = header_sofar;
>> }
>> }
>> /* if we found a match we can bail - unless of course we are
>> --
>> 1.7.4.1
>>
>> ___
>> notmuch mailing list
>> notmuch@notmuchmail.org
>> http://notmuchmail.org/mailman/listinfo/notmuch
>
> ping
>
> --
> Anton Khirnov
> ___
> 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] python/thread: always return a string in get_subject/authors
On Mon, 9 May 2011 09:06:34 +0200, Anton Khirnov wrote: > Now None is returned when those don't exist, which is inconvenient to > deal with. I'm not using the python bindings, but from a philosophical point of view, this change makes me a bit uncomfortable since it apparently merges two cases together, and makes an error (no Subject) indistinguishable from an odd situation (Subject of empty string). Or am I missing something here? All the best, David ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] python/thread: always return a string in get_subject/authors
Your commit message is inconsistent with your change; is your intent to return None or the empty string? Also, could you modify your commit message to say what "those" are? On May 9, 2011 3:06 AM, "Anton Khirnov" wrote: ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Use message-field-value instead of message-fetch-field in FCC header setup.
For message-fetch-field the buffer is expected to be narrowed to just the header of the message. That is not the case when notmuch-fcc-header-setup is run, hence a wrong header value may be returned. E.g. when forwarding an email, (message-fetch-field "From") returns the From header value of the forwarded email. Message-field-value is the same as message-fetch-field, only narrows the buffer to the headers first. --- The patch is for the release-candidate/0.6 branch. It is an amended version of a patch I sent a while ago id:"1278000507-22290-4-git-send-email-dmitry.kuroch...@gmail.com". Regards, Dmitry emacs/notmuch-maildir-fcc.el |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el index 3f1c124..aede753 100644 --- a/emacs/notmuch-maildir-fcc.el +++ b/emacs/notmuch-maildir-fcc.el @@ -80,7 +80,7 @@ will NOT be removed or replaced." (let ((subdir (cond ((or (not notmuch-fcc-dirs) - (message-fetch-field "Fcc")) + (message-field-value "Fcc")) ;; Nothing set or an existing header. nil) @@ -93,7 +93,7 @@ will NOT be removed or replaced." (error "Invalid `notmuch-fcc-dirs' setting (old style)")) ((listp notmuch-fcc-dirs) - (let* ((from (message-fetch-field "From")) + (let* ((from (message-field-value "From")) (match (catch 'first-match (dolist (re-folder notmuch-fcc-dirs) @@ -118,7 +118,7 @@ will NOT be removed or replaced." (concat (notmuch-database-path) "/" subdir) ;; finally test if fcc points to a valid maildir - (let ((fcc-header (message-fetch-field "Fcc"))) + (let ((fcc-header (message-field-value "Fcc"))) (unless (notmuch-maildir-fcc-dir-is-maildir-p fcc-header) (cond ((not (file-writable-p fcc-header)) (error (format "No permission to create %s, which does not exist" -- 1.7.5.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
release-candidate/0.6
On Sat, 07 May 2011 01:51:25 +0200, Florian Friesdorf wrote: > (..) > An open issue (also with gmime 2.4.24) is the extraction of a PDF from > an encrypted message via emacs (discussed on irc before, mentioned here > for completeness of the In the current release candidate this got fixed by Jamie. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: flo at chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC -- 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/20110509/1a3cc788/attachment.pgp>
[PATCH] sanitize notmuch-search output - rewrapped
this went out erroneously. On Mon, 9 May 2011 01:12:19 +0200, Florian Friesdorf wrote: > patch applies to current rc (ed6d3b8bb727b3acaa913945d6edf29843ab0864) > and works for me. It's the Andreas' patch just sent, that the commit > message will make it when applied with 'git am'. > > Andreas Amann (1): > Sanitize "Subject:" and "Author:" fields to not contain control > characters in notmuch-search > > notmuch-search.c | 22 -- > 1 files changed, 20 insertions(+), 2 deletions(-) > > -- > 1.7.5.1 > -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: flo at chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC -- 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/20110509/420d62cb/attachment.pgp>
[PATCH 2/2] test for sanitized notmuch-search output
--- test/corpus.ccs/cur/1:2, |8 test/search-output |8 test/test-lib.sh | 12 3 files changed, 28 insertions(+), 0 deletions(-) create mode 100644 test/corpus.ccs/cur/1:2, diff --git a/test/corpus.ccs/cur/1:2, b/test/corpus.ccs/cur/1:2, new file mode 100644 index 000..60081c4 --- /dev/null +++ b/test/corpus.ccs/cur/1:2, @@ -0,0 +1,8 @@ +From: "Two =?ISO-8859-1?Q?line=0A_author?=" +To: notmuch at notmuchmail.org +Date: Tue, 17 Nov 2009 21:28:37 +0600 +Subject: [notmuch] two =?ISO-8859-1?Q?line=0A_subject?= + headers +Message-ID: <123> + +body diff --git a/test/search-output b/test/search-output index 33ae119..202c13e 100755 --- a/test/search-output +++ b/test/search-output @@ -316,4 +316,12 @@ catOUTPUT +cat /dev/null +cp -a ${MAIL_DIR} ../corpus.ccs.mail +fi +} + test_begin_subtest () { if [ -n "$inside_subtest" ]; then -- 1.7.5.1
[PATCH 1/2] style fixes
---
notmuch-search.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/notmuch-search.c b/notmuch-search.c
index e7fc41a..fd7c7d1 100644
--- a/notmuch-search.c
+++ b/notmuch-search.c
@@ -112,13 +112,13 @@ format_item_id_text (unused (const void *ctx),
}
static char *
-sanitize_string(const void *ctx, const char *str)
+sanitize_string (const void *ctx, const char *str)
{
char *out, *loop;
loop = out = talloc_strdup (ctx, str);
-for(;*loop;loop++){
+for (; *loop; loop++) {
if ((unsigned char)(*loop) < 32)
*loop = '?';
}
--
1.7.5.1
[PATCH] sanitize notmuch-search output - rewrapped
patch applies to current rc (ed6d3b8bb727b3acaa913945d6edf29843ab0864) and works for me. It's the Andreas' patch just sent, that the commit message will make it when applied with 'git am'. Andreas Amann (1): Sanitize "Subject:" and "Author:" fields to not contain control characters in notmuch-search notmuch-search.c | 22 -- 1 files changed, 20 insertions(+), 2 deletions(-) -- 1.7.5.1
[PATCH] python/thread: always return a string in get_subject/authors
Now None is returned when those don't exist, which is inconvenient to deal with. --- bindings/python/notmuch/thread.py |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/bindings/python/notmuch/thread.py b/bindings/python/notmuch/thread.py index eebd6cb..cf26957 100644 --- a/bindings/python/notmuch/thread.py +++ b/bindings/python/notmuch/thread.py @@ -281,7 +281,8 @@ class Thread(object): """ if self._thread is None: raise NotmuchError(STATUS.NOT_INITIALIZED) -return Thread._get_authors(self._thread) +ret = Thread._get_authors(self._thread) +return ret if ret else '' def get_subject(self): """Returns the Subject of 'thread' @@ -291,7 +292,8 @@ class Thread(object): """ if self._thread is None: raise NotmuchError(STATUS.NOT_INITIALIZED) -return Thread._get_subject(self._thread) +ret = Thread._get_subject(self._thread) +return ret if ret else '' def get_newest_date(self): """Returns time_t of the newest message date -- 1.7.4.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
