Hi, * Vincent Lefevre [07-09-18 15:17:30 +0200] wrote:
On 2007-09-18 10:03:27 -0000, Mutt wrote:
I'd say lacking documentation is the bug (which I've fixed for now). For me it makes sense to use $charset as fallback because the text already is/was encoded in it, hence mutt can assume it can be converted exactly into it.
It doesn't necessarily make sense as the $charset may be completely local to the machine (e.g. 'x-my-charset'). I think that trying to convert the local charset to the last item of $send_charset, which should be the most general charset (e.g. utf-8), makes more sense.
In theory I agree. But $send_charset is user configurable and doesn't have to contain utf-8, it could even by empty. And still then, even with utf-8 (as in your case), conversion may fail not because the last item isn't generic enough but because the input is invalid.
Even in that case mutt has to do something.Without another conversion test, you could still let it default to utf-8 instead of $charset though.
I think it is important to let the user control the fallback.
I don't think that makes lots of sense since it's kind of micro-optimization, IMHO. Because at that point, no charset did fit and mutt is likely going to send out broken content anyway, so by letting the user control it you only give him the control in what specific way it's broken, not if it's broken at all.
For the case that all conversions failed because $send_charset is wrongly configured and the input is valid, $charset is the best choice, so I think it's really only about the case of broken input.
bye, Rocco -- :wq!