[REVISE coding-cookie] `coding:' cookie as lisp hook

REVISE coding-cookie It seems to me that the logical place for this is not a separate package, but fsf-compat. First, we already do provide a certain amount of coding-cookie recognition, enough to serve for communication among lisp programs and those external apps that use emacs-style cookies in a rigorously formalized way (mainly Python >= 2.3). Second, that would make it unnecessary to use a package-specific prefix for package identifiers. Otherwise, if convenient, perhaps the best way to handle this is to create the new package but not release it until revised, and then the author can work directly on it in CVS. N.B. I haven't checked the Makefile or package-info, just the code and Texinfo. Ville> Thanks, I'll have a look at this soon. Meanwhile, a short Ville> summary what this package exactly does, does it interfere Ville> with core functionality in any way (or duplicate it) etc Ville> would be nice. The package extends XEmacs's ability to guess coding systems from information about the file. The new variable `auto-coding-alist' partially duplicates the functionality of `file-coding-system-alist', but not in a harmful way, I think. It shadows the existing capability to recognize coding cookies, but doesn't interfere with any core functionality as far as I can tell, nor with latin-unity's cookie functionality (coding-cookie handles cookies at read time, while latin-unity handles them at save time, so they're complementary). However, the whole design of this feature shows just how broken coding cookies are (they're intended to be a final authority on the file's coding system, yet this short file provides not just one but two independent ways to override coding cookies!) Users demand the functionality, so I guess we want it, but the package should carry a warning that this is a gun that no matter where you point it, it's aimed at your foot. There is GNU-only functionality (buffer-is-unibyte) referenced; the package should be marked "experimental" until that kind of thing is reviewed and amended if necessary. It looks like the usage is harmless---the coding system implied is raw-text, ie, binary-with-eol- detection as in --with-file-coding=yes --mule=no. But since we don't support unibyte, it seems like a bad idea to support a cookie to deal with it. Naming is questionable, as it violates the normal package policy of choosing a prefix and using it consistently. (But this doesn't matter if the package contents end up in fsf-compat.) The package enables itself on load (second to last line). That's against XEmacs policy and _must_ be deleted before distribution. This causes no inconvenience (except for those who are violating policy by assuming that loading enables functionality) because exactly the same functionality is available through coding-cookie-enable, which is autoloaded. The documentation needs to be amended, as it explicitly says that loading the library enables the functionality. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py