Hi, * Vincent Lefevre [07-09-18 02:11:02 +0200] wrote:
On 2007-09-17 17:09:55 +0200, Rocco Rutte wrote:* Kyle Wheeler [07-09-17 09:39:02 -0500] wrote:
If mutt is generating this, then something is wrong... perhaps mutt should recognize and strip out //TRANSLIT strings?
Yes, but that's another issue (it already has a table of valid character set names, it just needs to match them for $send_charset).
Mutt doesn't need to recognize //TRANSLIT strings. The fact that I have a //TRANSLIT string in my $charset should not have any effect on what Mutt sends. $charset is only a terminal-related variable:
Character set your terminal uses to display and enter textual data.
See the other mail, $charset is a fallback for $send_charset. So yes, I think mutt should make sure that at least the charset chosen for sending something is valid. This way it's still perfectly legal to have a $charset value only valid with one's local iconv() implementation.
On the other hand, the question is what to do when all charsets in $send_charset fail and $charset does not match an officially assigned charset name, like in your case.
The options are 1) go ahead with a charset possibly not supported on the receiving side or 2) go ahead with a possible broken encoding in a valid charset.
I'm somewhat tending to prefer 2). bye, Rocco -- :wq!