Re: SEGV when replying to mail.

["M . Thielker" <balsa t-data com>]

Hi,

On 2001.08.27 14:06 Brian Stafford wrote:
> > reasonable. but why keep "us-ascii" as default ? i like iso-8859-1
> > much better ;)
> > peeve ;)
> 
> On the one hand, us-ascii is a good choice because the RFC 821/822 legacy
> makes e-mail a 7 bit medium.
> 
> On the other hand, since MIME encoding support is in place, the actual
> default
> should be an application preference.

No. The way it works is that it takes the charset from the body of the
original message and creates the reply body using that charset. Seems
reasonable, because the content of the original message will be quoted and
should therefore display properly in the newly created message body.
Legacy code in libmutt equates NULL to us-ascii, there is no choice. This is
not a preference, but a requirement and the default of us-ascii is not
changeable.
Of course, this strategy leads to numerous problems. How, for example, can I
reply to a message in simplified Chinese using roman letters? Two encodings,
but only one charset specifier.
So, sometimes a reply to a message is possible only in the charset of the
originator.
That also makes a twisted kind of sense, because when I get an email encoded
in us-ascii, it's likely that the senders terminal can only display
us-ascii. There's no point trying to reply with charset = iso-8859-1. His
terminal probably wouldn't display accented characters properly, anyway.
There is a reason to set the charset of a reply to the originator's charset.
Of course, most PC terminals today can display iso-8859-1 and only use
us-ascii as a convention. Us-ascii is a subset of iso-8859-1, rather, code
page 437 and 850 have a common subset, which fully contains us-ascii.
So, there may be a point in translating NULL into iso-8859-1, at that.

Melanie