[Bug: 21.4.12] mail-extr.el broken for ISO-8859-2

Simon Josefsson jas at extundo.com
Tue Mar 2 16:09:19 EST 2004


Hrvoje Niksic <hniksic at xemacs.org> writes:

>> Wasn't the right thing to track down how BBDB uses mail-extr, and
>> fix that?
>
> But the problem is not in BBDB, the problem is in mail-extr!  Message
> is also affected, but it's less annoying because you only see it in
> buffer names.  For example:
>
>     (mail-extract-address-components "Hrvoje Nikšić <hniksic at xemacs.org>")
>
>     -> ("Hrvoje Nik" "hniksic at xemacs.org")
>
> BBDB is not the right place to fix that bug.

I don't buy this completely.  Here's how I see things.  There is no
standard on how to split address components from non-ASCII strings.
Any attempt to implement that will be ad-hoc, and bound to fail in
some situations.  Instead, I believe the correct way is to invoke
address splitting (i.e., do RFC 2822 parsing on the header and extract
the proper fields) on the ASCII e-mail, and QP decode the appropriate
strings.  So BBDB should get the encoded word version of the header
data, and call m-e-a-c on that, and then QP decode the name.

Put simpler: QP decode followed by address splitting doesn't work.
Mail standards wasn't written that way.

Of course, fixing mail-extr.el to work on the above simple example
would be useful in practice, and I'd support any patch that achieve
that, if it doesn't cause any bad side effects.  Non-standards
conforming input may result in any output, so we might as well pick a
sane output.  But I suspect this is not the only bug caused by taking
short cuts when implementing the mail standards, so fixing BBDB might
be a better solution.




More information about the XEmacs-Beta mailing list