Received-SPF: pass (google.com: domain of pieter@praet.org designates
	10.180.8.226 as permitted sender) client-ip=10.180.8.226; 
From: Pieter Praet <pieter@praet.org>
To: Tomi Ollila <tomi.ollila@iki.fi>, Notmuch Mail <notmuch@notmuchmail.org>
Subject: Re: [PATCH v2 2/4] test: emacs: new test "notmuch-search: replying to
	a thread (sending)"
In-Reply-To: <m239a6wn4p.fsf@guru.guru-group.fi>
References: <1310313335-4159-1-git-send-email-pieter@praet.org>
	<1329683908-5435-1-git-send-email-pieter@praet.org>
	<1329683908-5435-3-git-send-email-pieter@praet.org>
	<m239a6wn4p.fsf@guru.guru-group.fi>
User-Agent: Notmuch/0.11.1+210~g6afc43e (http://notmuchmail.org) Emacs/23.3.1
	(x86_64-unknown-linux-gnu)
Date: Wed, 22 Feb 2012 19:49:06 +0100
Message-ID: <87mx8a900t.fsf@praet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list

On Sun, 19 Feb 2012 23:04:38 +0200, Tomi Ollila <tomi.ollila@iki.fi> wrote:
> On Sun, 19 Feb 2012 21:38:26 +0100, Pieter Praet <pieter@praet.org> wrote:
> > As pointed out in the previous commit, the test for replying from
> > within Emacs didn't actually submit the reply. This one does.
> > ---
> >  test/emacs |   41 +++++++++++++++++++++++++++++++++++++++++
> >  1 files changed, 41 insertions(+), 0 deletions(-)
> > 
> > diff --git a/test/emacs b/test/emacs
> > index 308d749..0f4f42b 100755
> > --- a/test/emacs
> > +++ b/test/emacs
> > @@ -273,6 +273,47 @@ On 01 Jan 2000 12:00:00 -0000, Notmuch Test Suite <test_suite@notmuchmail.org> w
> >  EOF
> >  test_expect_equal_file OUTPUT EXPECTED
> >  
> > +test_begin_subtest "notmuch-search: replying to a thread (sending)"
> > +$TEST_DIRECTORY/smtp-dummy sent_message &
> > +smtp_dummy_pid=$!
> > +test_emacs \
> > +'(let ((message-send-mail-function '\''message-smtpmail-send-it)
> > +       (smtpmail-smtp-server "localhost")
> > +       (smtpmail-smtp-service "25025"))
> > +  (notmuch-search "subject:\"testing message sent via SMTP\"")
> > +  (notmuch-test-wait)
> > +  (notmuch-search-reply-to-thread)
> > +  (end-of-buffer)
> > +  (newline)
> > +  (insert "Reply to a message via Emacs with fake SMTP")
> > +  (message-send-and-exit))' >/dev/null 2>&1
> > +wait ${smtp_dummy_pid}
> > +notmuch new >/dev/null
> 
> The above part smells like CopyPasteProgramming; (old version of) 
> emacs_deliver_message copied (old as this version is lacking
> opportunistic quit). 
>

Nope, "Sending a message via (fake) SMTP", around 2011-05 to be exact [1].

My main intention was to get a bugfix [2] applied (still isn't BTW),
which might have been expedited by providing a test which checks
whether messages are properly tagged 'replied' when and *only* when
applicable, and for that I needed a quick way to test replying to a
thread, so I lazily repurposed an existing test.  Not much point in
reinventing the wheel, is there?

Still haven't gotten around to writing the actual test to demonstrate
that messages are tagged 'replied' prematurely, but this should be the
gist of it:

  #+begin_src emacs-lisp
    ;; ask for confirmation (using `y-or-n-p') before sending
    (let ((message-confirm-send t))
      ;; temporarily redefine `y-or-n-p', immediately returns nil
      (flet ((y-or-n-p (&rest args) nil))
        ;; then try to send message (which will fail)
        (message-send-and-exit)))

    ;; Parent message should NOT be tagged 'replied' now, yet it is,
    ;; since `notmuch-message-mark-replied' is added to `message-send-hook'
    ;; instead of `message-sent-hook'.
  #+end_src


> Maybe the functionality of emacs_deliver_message needs to be
> split into 3 parts: initialization, sending and finalization.
> then other uses can use initialization and finalization parts
> and provide their own sending part.
>

That would be *much* better, indeed.


> I have work-in-progress code for initialization and finalization
> parts of that and I don't want to do the changes in 2 places...
>

OK.  I'll mark this patch (and the next, which depends on it) as 'wip',
and pick them up again when your refactoring efforts hit mainline.


> Tomi


Peace

-- 
Pieter

[1] id:"1305299270-4316-1-git-send-email-pieter@praet.org"
[2] id:"1305275652-22956-1-git-send-email-pieter@praet.org"