Norman Walsh <[EMAIL PROTECTED]> writes:
> I notice that BBDB 2.2 sometimes displays zip codes incorrectly. For
> example, the following address should have a zip code of 01002.
The zip codes are parsed in a specific function. That functions
thinks anything with 5 digits ought to be stored in a number,
therefore next time around, the leading zero has disappeared.
> I've long been puzzled by the attempt to store postal codes in some
> semantic way (as numbers or lists of strings). Would it not make more
> sense to store them as opaque strings (in V6, I suppose :-)
Yeah I guess you are right. The benefit is that this allows for
certain normalizations -- ie "CH-8004" and "CH - 8004" are parsed and
written as "CH-8004" the next time around. The drawback is that for
every stupid new zip code format, the parsing and printing functions
have to be updated. Ugh!
Maybe we should make it our goal for the next file version to switch
to plain strings... :)
> I ran into another problem with a three-part international postcode.
> The BBDB seemed to store all three parts, but it only displayed the
> first two, separated by a hyphen which didn't look right either.
All of this effects of the parsing and printing. The printing is
sometimes controlled by the datastructure, ie. if the first is a
string and the second is a string, then do this...
The "usual" way to deal with this is to extend the parsing and
printing functions in order to deal with this new "format" of zip
codes... very dirty... but I never dared to change that.
Alex.
--
http://www.geocities.com/kensanata/emacs.html
_______________________________________________
bbdb-info mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/bbdb-info
