On Tue, 2002-10-29 at 16:16, Stephen J. Turnbull wrote:
Thanks for looking into this, Stephen! Some comments below.
It seems to me that the logical place for this is not a separate
package, but fsf-compat.
Hmm, this is a Mule package, right? We'd need a
mule-packages/fsf-compat-mule or something.
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.
Sounds like a plan. Ilya, could you take a look at Stephen's comments
(included at the end of this message)?
However, the whole design of this feature shows just how broken
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!)
...and there's already some support for them in core and latin-unity. I
feel uncomfortable about scattering supposedly "broken" functionality
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
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.
scop at xemacs.org