[Bug: 21.4.12] mail-extr.el broken for ISO-8859-2
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