[PATCH] emacs: add missing paren to fix defun in notmuch-address.el.

[Tomi Ollila]

On Mon, Apr 08 2013, Karl Fogel <kfogel at red-bean.com> wrote:

> David Bremner <david at tethera.net> writes:
>>Karl Fogel <kfogel at red-bean.com> writes:
>>> This patch fixes a trivial missing-paren problem in notmuch-address.el
>>> (and reindents the following defun accordingly).  I'm not subscribed
>>> to this list, so please keep me CC'd on any followups.
>>
>>Dear Karl;
>>
>>Thanks very much for the patch.
>>
>>Since the offending commit is now reverted, it would be great if
>>somebody (TM) would combine your patch with  238bf4cb09.
>
> Oh, it's trivial.  The problem with 238bf4cb09 was simply that the
> function (defun) `notmuch-bbdb/snarf-headers' was missing a closing
> paren.  A visible symptom of this was that the *next* defun after it,
> `notmuch-bbdb/snarf-from', was spuriously indented inward.  If anyone
> had tried reindenting further, all the code below it would also have
> indented inward, making the problem more obvious.
>
> So the solution is to:
>
>   1) Re-apply the 238bf4cb09 patch
>
>   2) Add a parenthesis to the end of `notmuch-bbdb/snarf-headers',
>      such that the line "(bbdb-update-records addrs t t))" becomes
>      "(bbdb-update-records addrs t t)))"
>
>   3) Unindent the function `notmuch-bbdb/snarf-from' immediately below
>      there, which just means pulling each line leftward two spaces
>
>   4) Commit, push, profit :-).
>
> The above recipe is, of course, equivalent to re-applying the 238bf4cb09
> patch, then applying my patch (4c74ad313f608f0834961c63c70d1f811ef103b7)
> on top of it.  I'm not sure what the gitmost way to do that is, but if
> you want I can simply submit a combined change whose commit message
> makes clear what's going on.

The most tolerable way is to send new patch series w/ these 2 patches
that apply cleanly on top of current master (661dcf87aeb70) so that the
things that David needs to do are just to run `git am` and `make test`.

... also, proceeding this way helps getting reviewers to the changes,
which in turn makes changes more likely to be pushed to our master
repository.

> -Karl

Tomi