Re: [PATCH] test: use (format %S) to print nil in emacs test.
da...@tethera.net writes: From: David Bremner brem...@debian.org 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
[PATCH] test: canonicalize content-type in "Sending a message via (fake) SMTP"
LGTM. Quoth david at tethera.net on Aug 30 at 8:24 pm: > 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. > --- > > as discussed on IRC, the $ is not quite as nice as \b, but it is > POSIX.2, at least according to "man 7 regex" > > test/emacs |5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/test/emacs b/test/emacs > index afe35ba..5d118b6 100755 > --- a/test/emacs > +++ b/test/emacs > @@ -169,7 +169,8 @@ emacs_deliver_message \ > (insert "To: user at example.com\n")' > sed \ > -e s',^User-Agent: Notmuch/.* Emacs/.*,User-Agent: Notmuch/XXX > Emacs/XXX,' \ > --e s',^Message-ID: <.*>$,Message-ID: ,' < sent_message >OUTPUT > +-e s',^Message-ID: <.*>$,Message-ID: ,' \ > +-e s',^\(Content-Type: text/plain\); charset=us-ascii$,\1,' < > sent_message >OUTPUT > catFrom: Notmuch Test Suite > To: user at example.com > @@ -178,7 +179,7 @@ Date: 01 Jan 2000 12:00:00 - > User-Agent: Notmuch/XXX Emacs/XXX > Message-ID: > MIME-Version: 1.0 > -Content-Type: text/plain; charset=us-ascii > +Content-Type: text/plain > > This is a test that messages are sent via SMTP > EOF
[PATCH] test: use (format "%S") to print nil in emacs test.
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. 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
[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 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
