The new ChangeLog is attached below. It turned out much bigger than
what I had planned to do.
-
I introduced a new variable bbdb-address-format-list for more
flexible address formatting and editing. Rules are based on country
names if this field is defined. Otherwise a customizable default is
used. I hope that the new code allows to handle in a fairly
convenient and flexible way the different formats used in different
countries. Hard-coded solutions such as
bbdb-format-address-continental and bbdb-address-edit-continental
should be obsolete now. I kept one set of such functions to have an
example if someone still wants to define his or her own functions
for this.
On Tue Feb 8 2011 Luca Capello wrote:
> On Thu, 03 Feb 2011 05:31:50 +0100, Roland Winkler wrote:
> > On Wed Feb 2 2011 Johnny wrote:
> >> This is a good idea; the current BBDB handling seems very
> >> US-centered. For one, I think "Postal code" should replace the American
> >> term "Zip code" as default naming, as this seems to be the generic
> >> term.
> >
> > This becomes yet more complicated. I vaguely remember that some
> > other english-speaking countries use yet different names instead of
> > "zip code" and "postal code", but I forgot where it was and what
> > their alternative terminology was...
>
> Well, I would say that by default we should use the same term used by
> the UPU, which is "Postcode" [1], albeit quite surprisingly the main
> article on Wikipedia is referred as "Postal Code":
Oh well... I do not want to discriminate anybody... "postcode" has
the wonderful advantage of being a bit shorter than "postal code".
And maybe, it can treat all bbdb users the same by being a term that
is not used anywhere else but in some administrational guidelines
and in bbdb!
-
Previously, the labels for note fields were saved in between
sessions in the bbdb data file. Yet I thought there is no point in
saving those whereas bbdb-phone-label-list and bbdb-address-label-list
are always recalculated. So now the value of bbdb-notes-label-list is
recalculated, too. This means that now one can remove the header
line starting
;;; user-fields:
from bbdb-file. In a way, this is a change of the format of the data
base. But it should be completely backward compatible as it was
never a problem for bbdb if the user-fields were not saved in the
database.
-
Editing phone numbers now allows one to change the format of an
existing entry from North American numbering plan (NANP) to the
freestyle format and back.
-
On Fri Feb 4 2011 Antoine Levitt wrote:
> I've got an issue with the bbdb-complete-name function. When using
> another completion in message mode, such as
>
> (setq message-tab-body-function (lambda () (interactive) (dabbrev-expand
> nil)))
>
> , a successful BBDB completion also triggers the dabbrev-expand
> completion.
>
> I'm not entirely sure what the return value should be in all
> circumstances, but in the one described above it should be t, so
> that message doesn't try to complete.
I have now given the command bbdb-complete-mail (formerly
bbdb-complete-name) a well-defined return value. It is non-nil only
if the string preceding point is a valid completion so that the
above problem should not exist anymore.
The old code of bbdb-complete-name also used expand-abbrev as a fall
back if bbdb-expand-mail-aliases was non-nil. Yet I thought this were
really too many concepts stuffed into the function bbdb-complete-name.
If one uses instead the new return of bbdb-complete-mail, one can
now simply use something like
(defun my-bbdb-complete-mail ()
(interactive)
(or (bbdb-complete-mail)
(mail-abbrev-complete-alias)
(expand-abbrev)))
and one can easily permute the order of these calls depending on
one's taste.
-
The function bbdb-mua-wrapper contained a bug as it did not work for
mail and message mode. This is fixed.
-
On Sun Feb 13 2011 Antoine Levitt wrote:
> 13/02/11 15:31, Roland Winkler
> >> I think the let should be before the if in
> >> bbdb-mua-pop-up-bbdb-buffer. Or even better, bbdb-insinuate would hook a
> >> function to notice contacts, independently from pop-ups.
> >
> > I guess from your perspective bbdb-mua-pop-up-bbdb-buffer is, first
> > of all, a misnomer. The main action is hidden in
> > bbdb-mua-update-records. -- I'll look into this.
>
> Yes. Maybe there should be two separate functions added to the hook, one
> for noticing and the other for displaying the popup.
Two functions would duplicate things, which is something I'd like to
avoid. Instead, I renamed bbdb-mua-pop-up-bbdb-buffer to
bbdb-mua-auto-update, which, I believe, gives a much clearer idea
what the main purpose of this function is. And bbdb-mua-pop-up-bbdb-buffer
is tested after calling bbdb-mua-update-records.
In a similar spirit, I also renamed bbdb-mua-pop-up-init to
bbdb-mua-auto-update-init. Also, I extended the doc strings for
bbdb-mua-auto-update-init a