Question about how to specify coding system chains: encoding or decoding persepctive?

ben> Now that I've created chains of coding systems <SHRIEK> Yeeeeeeeeeeeeeeeeess! </SHRIEK> ben> there's a clear standard, which hopefully is the most ben> intuitive. What's wrong with the verbose convention? bytestream-to-gzip / gzip-to-bytestream utf8-to-euc-jp / euc-jp-to-utf8 utf8-to-internal / internal-to-utf8 bytestream-to-base64 / base64-to-bytestream dos-eol-to-unix-eol / unix-eol-to-dos-eol This can easily be computed algorithmically if you require the name be as invertible as the process. Provide an aliasing facility for common cases like gzip : bytestream-to-gzip / gunzip : gzip-to-bytestream crlf-to-nl : dos-eol-to-unix-eol / nl-to-crlf : unix-eol-to-dos-eol tarc : fso-set-to-tar / tarx : tar-to-fso-set and so on. (fso-set = "set of file system objects") ben> so, what do people think: given that we for the moment are ben> talking about processes where the result of *decoding* is ben> just the text, should we consider as basic the steps required ben> to decode: I think users will generally encounter the problem in the form of "this damn attachment I need to decode and my MUA doesn't do it (yet)." OTOH, I expect developers will normally be quite symmetric. Eg, MUA authors must be able to both encode and decode MIME. So although I prefer a verbose API with symmetric (computable) names, if you insist on one name going both ways, I prefer to consider decoding the "normal" activity, encoding the inverse activity. I think this one name, two directions convention is a mistake, though, because people's intuitions will differ from each other, and from case to case. Eg, I'm getting used to it now, but when I first started doing M-: (decode-coding-region (point-min) (point-max) 'iso-2022-jp) RET, I was always confused about which way was encoding and which decoding. Also, IMHO, we should avoid terms like "forward," "reverse", or "undo" in the documentation if we use the one name, two directions convention. "Inverse" is more abstract, so better. Maybe there's something even better than that. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."