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

Ville> Hmm, this is a Mule package, right? We'd need a Ville> mule-packages/fsf-compat-mule or something. Not necessarily. A Mule package is one that contains constructs that harm a non-mule XEmacs just by loading them. Non-ISO-8859-1 characters, for example. However, with no eval-when-compile constructs and with the call to -enable deleted, this should be OK; there's no way to get any of those functions called unless the user does something like M-: (coding-cookie-whip-me-beat-me-stomp-me-with-your-high-heels-ooh :-). Ville> ...and there's already some support for them in core and Ville> latin-unity. I feel uncomfortable about scattering Ville> supposedly "broken" functionality around. Well, as Ilya points out in the .texi, this is a difference of opinion. I'm not going to introduce the functionality he wants in 21.4, and not in 21.5 any time soon. We really need a "cookie" facility that recognizes usages that are enforced by standards, where the relevant packages can push a recognizer (eg, a function or regexp) on a list. Then python-mode can push "-\*-.*coding: \(\s_*\)", and psgml "<meta http-equiv=\"content-type\" content=\".*charset=\(.*\)\"" etc on that list, and be confident they'll work because they are enforced by the language standard. What I object to is random hand-maintained cookies hiding in comments. But there really is a lot of demand for this among a certain class of users, especially Japanese and Russians. Those users don't have anything reliable: EUC-JP, Shift JIS, and KOI8 (and Big 5, but we don't seem to have so many Taiwanese users) are for better or worse quasi-national standards, and they're not reliably distinguishable from international standard encodings also in common use by any of our usual tricks. There's some hope for 21.5 with Ben's new detection mechanism, but for now a lot of users prefer to use cookies. As a maintainer, I'm not particularly happy, but we need to support our users. Just tag it like RMail. "New and obsolete; if you don't know, you don't need it; if you aren't using it, don't start." :-) -- 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

Ilya> Changed and documented. Thanks. I took a quick look at this, but it's going to be a couple of days before I can spend real time on it. Looks good so far. Ilya> If somebody is going to create new CVS module for the Ilya> package: I am already registered as CVS committer, needing Ilya> only permission to write into that module. Right, that's what I meant. Thanks for pointing out you're already a committer, I forgot to mention that. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.