On 2012-01-21, Uday Reddy <[email protected]> wrote: > My idea is not to transcode in anything. Just decode it to Emacs internal > coding and leave it at that. The folder can be saved to disk using whatever
That is transcoding... > coding Emacs or the users chooses. It could be an ISO coding, for instance. > The coding used to save the folder is not VM's concern. Only if, as you suggested, you prohibit any manipulation of the folder file outside VM. Suppose you use ISO2022. That's a stateful encoding, so if you have, say, two Japanese messages in a row, if you pull out the second one by itself from the disk file, you won't know that it's Japanese. What will you do with win1252 messages, a character/coding set that has no internal representation, even in the Emacs super-ISO (ESC-quoted) coding system? You will, by necessity, transcode them to a standard set. Or character sets that exist, but which the Emacs installation you're currently using doesn't happen to have defined? (For example, I don't have the legacy Thai or Indian systems defined in my Emacs, because I need the limited charset space for other things.) Another trouble is that Emacs (certainly XEmacs, but I think also Emacs) is not robust wrt character encodings. Generally, you can lose data without being aware of it, because (de/en)coding happens so low down that there's no easy way to return an error. For example, half a year's worth of my non-English mail is unrecoverably mangled by one of the many VM coding-system problems I've fixed over the years - because I got no warning at the time that anything was going wrong. (Now I've patched my XEmacs to at least warn of trouble.) >> Why no charset headers? If you're munging a mime message, you should >> ensure that it remains a valid mime message. > Is it not valid mime to have text/plain parts without a charset parameter? Oh, it's valid - but a missing charset parameter MUST be treated as us-ascii. I'm not saying your scheme is impossible - or even difficult to do - just that there are an awful lot of things to be very careful about.
