From: Tomi Ollila <tomi.ollila@iki.fi>
To: Austin Clements <amdragon@MIT.EDU>, david@tethera.net
Subject: Re: [PATCH] test: use (format "%S") to print nil in emacs test.
In-Reply-To: <m23933lcod.fsf@guru.guru-group.fi>
References: <1346375399-449-1-git-send-email-david@tethera.net>
	<20120831035227.GH11179@mit.edu>
	<m23933lcod.fsf@guru.guru-group.fi>
User-Agent: Notmuch/0.14+11~gd9bf007 (http://notmuchmail.org) Emacs/23.1.1
	(x86_64-redhat-linux-gnu)
Date: Fri, 31 Aug 2012 14:38:32 +0300
Message-ID: <m23933jnpj.fsf@guru.guru-group.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: notmuch@notmuchmail.org, David Bremner <bremner@debian.org>
Precedence: list

On Fri, Aug 31 2012, Tomi Ollila <tomi.ollila@iki.fi> wrote:

> On Fri, Aug 31 2012, Austin Clements <amdragon@MIT.EDU> 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@tethera.net on Aug 30 at 10:09 pm:
>>> From: David Bremner <bremner@debian.org>
>>> 
>>> 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