Re: mail-extract-address-components extract modified full name

[Katsumi Yamaoka]

>>>>> In <address@hidden>
>>>>>   Simon Josefsson <address@hidden> wrote:

> Stefan Monnier <address@hidden> writes:

>> The function is supposed to receive ASCII input, so it's no wonder it might
>> break in other circumstances.  Why ASCII input?

I didn't know the function is only for ASCII characters until
quite recently.  It is because the function looks like a generic
function and works with non-ASCII characters after a fashion.
In addition, I cannot imagine who needs the voodoo function.  It
seems very much personalized for (by?) someone.  Why isn't it
sufficient to extract and separate name and address portions
simply without any modifications?  It can be done later if
needed, though.

[...]

> IMHO, there should be two packages:

> 1) Proper RFC (2)822 parser.  There is rfc822.el but it is
>    insufficient, and I'm not sure it is correct -- it uses regexp's a
>    lot, but I recall that the "correct" 2822 grammar, expressed as
>    regexp's, is much more complex than what rfc822.el does.
>    Naturally, it should only accept valid RFC 822 input, which is
>    ASCII only.

>    (Incidentally, the QP encoder/decoder need to use this package,
>    since QP must only be applied to certain RFC 2822 grammatical
>    terminals, not all text, and I believe the current QP
>    encoder/decoder doesn't do this properly.)

> 2) Ad-hoc approach that split real world textual e-mail address,
>    including non-ASCII, into its components.  Might use the proper
>    parser, at least partially.  Perhaps similar to what Katsumi
>    Yamaoka proposed.

3) Disable the voodoo function by default.  Since using the
   following form seems helpful not to break Japanese names.

   (eval-after-load "mail-extr" '(defalias 'mail-extr-voodoo 'ignore))

   Furthermore, I think the voodoo function should be moved to
   the language or the international subdirectory.
-- 
Katsumi Yamaoka <address@hidden>