[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] org-bbdb-anniversaries gives error 'bad sexp'
From: |
Matt Lundin |
Subject: |
Re: [O] org-bbdb-anniversaries gives error 'bad sexp' |
Date: |
Mon, 16 May 2011 10:03:46 -0400 |
User-agent: |
Gnus/5.110017 (No Gnus v0.17) Emacs/24.0.50 (gnu/linux) |
"Roland Winkler" <address@hidden> writes:
> On Sun May 15 2011 Matt Lundin wrote:
>> I'd be happy to take this on. AFAICT, there are three functions in
>> org-bbdb that no longer exist in bbdb v3.
>>
>> bbdb-name
>> bbdb-company
>> bbdb-record-getprop
>>
>> The first two can easily be defaliased to bbdb-search-organization and
>> bbdb-search-name. (For a while, we should probably support bbdb v2 and
>> v3 simultaneously.)
>
> Things might be a bit more subtle. The new organization field is
> a list, not a single string.
Thanks. That's good to know. AFAICT, bbdb-search-organization already
accommodates for this fact. That is, if you give it a regexp, it will
return all records matching the regexp in the organization field. Since
org-bbdb calls bbdb-company with a string as an argument, wouldn't a
defalias be sufficient for the time being?
>> The other major change that breaks compatibility is the order of the
>> parameters in bbdb-split. It has been reversed in the new bbdb: i.e.,
>> one used to call (bbdb-split string separator), whereas now one must
>> call (bbdb-split separator string). Is there a compelling reason to
>> change this order in the new bbdb?
>
> The change is not only with respect to the order of arguments that
> could be reverted in BBDB v3. More importantly, I tried to get rid
> of hard-coded separators. Most often the separator arg is now the
> name of the field that is split. Then the actual separator is looked
> up in bbdb-separator-alist. While I do not know yet a good strategy
> for the upgrade of org-mode's BBDB interface, I'd find it
> unfortunate if such a feature was lost in org-mode to preserve
> backward compatibility.
Thanks for the explanation. For the time being, I'll add a workaround to
accommodate both versions.
Best,
Matt