Re: 21.5 crash in Gnus

["Stephen J. Turnbull" <stephen@xemacs.org>]

>>>>> "Reiner" == Reiner Steib <reinersteib+gmane@imap.cc> writes:

    Reiner> On Wed, Mar 15 2006, Stephen J. Turnbull wrote:
    >>>>>>> "Reiner" == Reiner Steib <reinersteib+gmane@imap.cc>
    >>>>>>> writes:

    Reiner> On Tue, Mar 14 2006, Stephen J. Turnbull wrote:

    >>>> However, Gnus's I18N misfeatures are legion;

    Reiner> Care to explain?  Or give us some URLs or MIDs?

    Reiner> Is anyone interested in investigating these problems?

I'm not.  These bugs generally bite me while I'm doing something
moderately destructive such as a save-and-strip-mime, which of course
makes replication impossible.  I've had great trouble understanding
the Gnus code, so it's extremely difficult to localize bugs.

> Here are the reasons that bit me this week:
>
> 1.  Something isn't checking for the coding-system `gnus-decoded',
>     which gets propagated as a buffer-local value (typically the
>     *Article* buffer) of some coding system variable used by nnmail,
>     thus making the error essentially permanent until you kill the
>     buffer.

I haven't seen this recently.

> 3.  Every time you edit a mail, the RFC2231-encoded parameters get
>     re-encoded when you save.  This is particularly annoying when
>     somebody sends you a 15-attachment mail.

Still the case.  Should be easily reproduced.

> 4.  The code for viewing MIME parts doesn't seem to grok RFC2231;
>     clicking on an encoded external body gives a "I can't find any
>     file with a name that seems to be RFC2231-encoded" error.

Still the case.  Should be easily reproduced.

    >> 5.  There's no proper way to set the charset parameter when
    >> editing a message.

    Reiner> You can set mm-coding-system-priorities locally, at least
    Reiner> in Emacs.

You call that "proper"?  I'll try it the next time it's relevant, but
it is not a reasonable interface.  Editing the mail in a separate
buffer in fundamental mode is far more convenient and reliable.

> 6.  Address headers don't get RFC2047-encoded in Japanese mail.  (This
>     is a multiple regression, sometimes it works, sometimes it don't,
>     lather, rinse, repeat.)

Haven't had a problem with this recently.

> 7.  Gnus doesn't seem to provide a useful way to "wash" mail with a
>     broken Content-Type header.

Haven't run into this in a while.

New one:

8.  Message mode handles headers of the form

    To: taro@tsukuba.net (筑波太郎)

    improperly, where the header was automatically generated as a
    reply, and the content of the comment was ISO-2022-JP-encoded
    Japanese.  It produces this:

    To: taro@tsukuba.net =?ISO-2022-JP?B?KBskQkNeR0hCQE86GyhCKQ==?=

    which is of course an erroneous address according to RFC 2822.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.