Re: [PATCH] emacs: bugfix notmuch-mua-reply when signature is present

[Tomi Ollila <tomi.ollila@iki.fi>]

On Wed, Aug 28 2013, Tomi Ollila <tomi.ollila@iki.fi> wrote:

> On Thu, Aug 08 2013, Geoffrey Ferrari <geoffrey.ferrari@oriel.oxon.org> wrote:
>
>> From: "Geoffrey H. Ferrari" <geoffrey.ferrari@oriel.oxon.org>
>>
>> When composing a reply, notmuch-mua-reply tries to be smart and cite
>> the original message by inserting it before the user signature, if
>> one is present. However, the existing method of backward searching
>> from the end of the buffer to find the signature separator and then
>> moving one line up results in the original message being cited in
>> the message headers. That's because at this point the message looks
>> like this (with | representing point after searching for the
>> signature separator):
>>
>> From: xxx
>> To: xxx
>> Subject: xxx
>> --text follows this line--
>> |--
>> My fancy signature
>
> Now that I tested, (with ~/.signature), composing new mail starts with
>
> --8<---8<---8<---8<---8<---8<---8<---8<---8<-
> From: Tomi Ollila <tomi.ollila@iki.fi>
> To:
> Subject: 
> Fcc: /home/too/mail/mails/sent
> --text follows this line--
>
> --
> signature
> --8<---8<---8<---8<---8<---8<---8<---8<---8<-
>
> Notice the empty line between '--text follows this line--' and '--'
>
> In your example, the signature block is -- for some reason --
> inserted without the empty line.
>
>> With this patch, a newline is opened instead, so that the orignal
>> message is cited above the signature but still in the message text.

....

>>       (goto-char (point-max))
>>       (if (re-search-backward message-signature-separator nil t)
>>-	  (forward-line -1)
>>+	  (newline)
>>	(goto-char (point-max)))

If the case is like I think, it should have used (open-line 1) instead.

Anyway, what about:

    (goto-char (point-max))
    (when (re-search-backward message-signature-separator nil t)
      (forward-line -1)
      (unless (eolp)
        (end-of-line)
        (newline)))

The else clause with (goto-char (point-max)) is unnecessary as 
with the third argument NOERROR being t point is moved if
re-search-backward doesn't find match.

>> ---
>
> Tomi

Tomi