From: Sebastian Lipp <bacuh@riseup.net>
To: Karl Fogel <kfogel@red-bean.com>
Subject: Re: [PATCH] emacs: add missing paren to fix defun in
	notmuch-address.el.
In-Reply-To: <87oax6vt4u.fsf@ktab.red-bean.com>
References: <87wqsfik5l.fsf@floss.red-bean.com>
	<87mwtah2hd.fsf@zancas.localnet>
	<877gkeau42.fsf@floss.red-bean.com>
	<m2ppy5v3mc.fsf@guru.guru-group.fi> <8738v1jtzc.fsf@nikula.org>
	<87k3odgutd.fsf@zancas.localnet> <87ip3wbj7g.fsf@mcs.anl.gov>
	<m2hajgxli5.fsf@guru.guru-group.fi>
	<87vc7vgbym.fsf@zancas.localnet>
	<m2ehejykb1.fsf@guru.guru-group.fi>
	<87pphmc604.fsf@verb.i-did-not-set--mail-host-address--so-tickle-me>
	<87oax6vt4u.fsf@ktab.red-bean.com>
User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.1
	(i686-pc-linux-gnu)
Date: Sun, 06 Jul 2014 22:37:40 +0200
Message-ID:
 <87bnt2dy0b.fsf@verb.i-did-not-set--mail-host-address--so-tickle-me>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Tomi Ollila <tomi.ollila@iki.fi>, notmuch@notmuchmail.org
Precedence: list

Karl Fogel <kfogel@red-bean.com> writes:
> Sebastian Lipp <bacuh@riseup.net> writes:
>>diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el
>>index fa65cd5..ee7b169 100644
>>--- a/emacs/notmuch-address.el
>>+++ b/emacs/notmuch-address.el
>>@@ -113,6 +113,59 @@ to know how address selection is made by default."
>> (when (notmuch-address-locate-command notmuch-address-command)
>>   (notmuch-address-message-insinuate))
>> 
>>+;; functions to add sender / recipients to BBDB
>>+
>>+(defvar bbdb-get-addresses-headers)
>
> I think it's good to include an initial value (even an invalid
> placeholder one, if the real initialization has not happened yet), and a
> doc string.  C-h f defvar RET will say more about how to do that.

I hope I got that right now. (I've got no real clue of Lisp yet because
I just recently switched to emacs partly because of notmuch. :)

How about

    (defvar bbdb-get-addresses-headers nil
      "List of Addresses to import into bbdb")

?

> (By the way, this isn't a user-customizeable variable, right?  If it
> were, then `defcustom' would be better than `defvar'.)

As far as I understand it: It's not.