The package enables itself on load (second to last line).
against XEmacs policy and _must_ be deleted before distribution.
Changed and documented.
What about requiring the same from `viper', which currently may
viperize on loading when certain variable is set?
The new variable `auto-coding-alist'
partially duplicates the functionality of `file-coding-system-alist',
Added a new documentation chapter describing how package interferes
with core XEmacs. Agree that `auto-coding-alist' duplicates core
functionality. It was left there to facilitate updating from new
Emacs version. Perhaps should be deleted entirely (with documenting
it in comment).
normal package policy of
choosing a prefix and using it consistently
Doing nothing to naming inside package. The reason is the same:
facilitating updating from Emacs.
There is GNU-only functionality (buffer-is-unibyte) referenced; the
package should be marked "experimental" until
I don't see `buffer-is-unibyte' in package elisp code. What sort of
reference do you mean? What field in package mark it as
"experimental"? I don't see such a word in package system
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.
If somebody is going to create new CVS module for the package: I am
already registered as CVS committer, needing only permission to write
into that module.
With all this, here is new package version.