add ansi-color.el to XEmacs?

Alex> Maybe you want to add ansi-color.el to XEmacs? It is Alex> already part of Emacs. Among other things, it looks to be the obvious answer to the new color-gcc FAQ. At least one person has reported that it solves that one. I support adding this one. It looks to me like it fits best into our os/os-utils "miscellaneous OS utilities" package. It's not really a comms package (in the sense of our package classification) and it's probably better there than in oa/pc which is (currently) focused on keymap hacks. You can take a look in etc/PACKAGES to see if there's a category you like better, if you prefer. Some questions: 1. We would probably want to add the ansi-colors Custom group to relevant XEmacs-specific groups (in particular, package system related groups). This would best be done in ansi-colors.el itself, probably conditional on (featurep 'xemacs). Any problem with that? 2. Does it make sense to add the finder keywords "terminals" and/or "services"? terminals support for terminal types services provides services for use by other programs (cf `user') 3. If you wanted to, you could support this as a "regular" XEmacs package. Then it would be listed explicitly in the list-packages interface, browsable by users unfamiliar with it. (NB. This may be controversial with other members of the Review Board, as our existing package-ui utilities don't really scale to adding dozens of packages. It is certainly an option for discussion, though.) This would involve extra effort on a one-time basis to add some package infrastructure files, including a trivial Makefile, to support building the packages. Maintenance of the infrastructure is normally trivial (bumping your version number at release time), and if the package system should change, you can expect us to provide porting tools, consultation, and labor. This would also allow you to export the bleeding edge via our anonymous CVS server, and give you much more control over what we distribute. (Not 100%, but if you wanted that it wouldn't be GPL, right?) 4. If not, normally people who maintain XEmacs packages or parts of them are granted access to the relevant package on request. If you wanted to, you could almost treat the XEmacs anonymous CVS server as the primary mirror of your primary repository, as in 3. The advantage would be that somebody else would take care of all infrastructure issues. The disadvantage is that divergence is much more likely, since random XEmacs developers tend to treat those packages as "part of XEmacs" rather than "externally maintained." The default option is "you contribute, we synch when we feel like it, nobody cries if the code diverges." Regards, -- 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."