emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RMAIL bails out with coding-system-error


From: Simon Josefsson
Subject: Re: RMAIL bails out with coding-system-error
Date: Sun, 05 May 2002 17:11:50 +0200
User-agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Economic Science, i686-pc-linux)

Eli Zaretskii <address@hidden> writes:

> On Sun, 5 May 2002, Simon Josefsson wrote:
>
>> Is this X-Coding-System header actually used by RMAIL for anything?
>
> Yes, it is used to set the value of buffer-file-coding-system when you 
> read the same message later.  Without this, RMAIL would have to 
> repeatedly decode messages each time you display it; this would be a 
> nuisance with long messages.
>
> In addition, recording an encoding allows features like 
> rmail-redecode-body, that lets users override bogus MIME headers.

I wasn't clear, I meant: Is it used for anything upon receiving a
message with that header from the network via email?

Using it internally after receiving the message is OK, I think.

>> I think the header is a very bad idea and it should be removed.  There
>> is a standard for interchanging non-ASCII data using email, and it is
>> called MIME.  Inventing something new that is specific to emacs (and
>> can even depend on which additional packages are installed..) is a
>> perfect method to cause problems for users and make people reject the
>> entire software because it doesn't follow standards.
>
> IIRC, the X-Coding-System header is only written to the BABYL-formatted 
> files Emacs keeps for itself, and then only in the summary part.  What 
> kinds of problems do you envision with this, given that headers beginning 
> with "X-" can be used by applications for their own purposes?

None.  I thought RMAIL decided how to display an incoming email
depending on the X-Coding-System header.  This is what would cause
problems.

Of course, RMAIL should probably make sure that X-Coding-System is
removed when forwarding messages, so other RMAIL instances isn't
confused.  Or at least remove it on incoming messages before adding
the new header locally.

> However, I'm not saying that this is the only possible way of recording 
> the message encoding.  If there are more standard methods that can 
> support the same features, we could consider switching to them.

For internal purposes, whatever works is OK.  Switching to MIME for
the internal representation seems like work with little gain.

>> Gnus provides
>> two supposedly standalone packages called Message and Emacs MIME which
>> provides MIME encoding and decoding, can't RMAIL use them?
>
> The difference between RMAIL and Gnus is that RMAIL stores only the 
> decoded messages.  It doesn't keep the undecoded copy around.  But I 
> don't know if this should prevent the change of the kind you suggest.

Ok.  I misunderstood the purposes of the header.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]