Malcolm> Note that I'm asking about accepting and ignoring the Malcolm> keyword, not necessarily implementing the underlying help Malcolm> system. I don't have any problem with this as long as it's clear we _can_ support the help system without too much effort if users demand it. Malcolm> Before I start on developing some patches to improve Malcolm> compatibility I'd like to know if they'd be accepted in Malcolm> principle. How far should we go in supporting the GNU Malcolm> Emacs API? Until your stomach turns? :-) To put it more constructively, right now we don't have the manpower to refactor everything. If you've got GNU code that you'd like to port, and porting some missing API (if only as a stub) would be not much more effort than kludging around it, why not? You'll save somebody else the trouble. I think that documenting the stubbed functionality in the nearest docstring is an absolute must. There should be a standard keyword for it, to make grepping easy. Eg, "The XYZ functionality is unimplemented [GNU compatibility stub]." I think it might be desirable to have an XEmacs debug API called `maybe-bitch-about-stubbed-gnuemacs-functionality', which issues a warning if `warn-about-stubbed-gnuemacs-functionality' is non-nil. This would be useful for people who don't care about the functionality per se, but would like to contribute a fix or two for the sake of completeness, to see what actually gets called in their usage. Maybe there should be a list of these, perhaps in a TODO node in the Internals manual. -- School of Systems and Information Engineering 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.