Hello,

On Mon, 7 Mar 2005 11:15:06 +0100
Godwin Stewart <gstewart@xxxxxxxxxx> wrote:

> Actually, it doesn't. Or at least not here, it doesn't. If it did,
> this (malformed) message http://www.bonivet.net/misc/example_mail.txt
> which does use ISO-8859-15 characters (and my locale is ISO-8859-15)
> would not be rendered like this:
> http://www.bonivet.net/misc/sylpheed_msg_view.png, but like this:
> http://www.bonivet.net/misc/sylpheed_msg_view_ok.png.

I could display the message correctly with locales such as en_US,
de_DE, de_DE@euro (with default setting).

> For it to use locale encoding by default, it would need things like
> this in procmime.c and textview.c (from memory it's those 2 files):
> 
> if ( !prefs_common.force_charset && !mimeinfo->charset )
> 	charset = conv_get_locale_charset_str();

In the current code, if charset is NULL and passed to
textview_write_line(), eventually conv_iconv_strdup() is called with
(inbuf, NULL, NULL), and it does locale-encoding-to-UTF-8 conversion.
Can you retry with plain 1.9.5?

> > and forcing encoding is available, I think there's not much problem
> 
> It is, yes. But if another mail turns up correctly encoded in a
> different codeset than the one the user just forced, it will get
> rendered with the wrong codeset meaning that the user has to turn the
> "force charset" feature off again to view the new mail correctly.
> 
> The "fallback codeset" has the advantage of only applying to mails
> that don't specify which codeset they use and therefore not
> interfering with correctly encoded mails, which is why I wrote it in
> the first place.

I see the advantage, but cluttering user-interface is one problem.

> Maybe I could be so bold as to suggest using the fallback codeset
> instead of the force codeset, rather than in addition to the force
> codeset? Its behaviour is, IMHO, preferable in that it leaves
> correctly encoded stuff alone.

Force charset setting is for broken messages, which specify wrong
charsets (different from actually used one). Fallback charset can't
handle such messages.

-- 
Hiroyuki Yamamoto <hiro-y@xxxxxxxxxx>