Re: XEmacs Module (was Re: [VETO] Re: XEmacs-21.4.5 ...)

Not that I should really stick my 2 cents in, but as someone who also uses the XEmacs module feature, I don't see what the big deal is about XEmacs modules having access to the XEmacs internals. Sure, it would have been nice, back when Emacs/XEmacs was young and small to have thought about externally written plug-ins, but I suspect that any good solution might require a fair bit of rearchitecting, and at low levels too. The current solution is that you need to know how to find the functions you're looking for inside XEmacs, and release your module to be tied to a specific XEmacs major/minor release. I know that my module needed to be modified between 21.1 and 21.4 because of some API changes, and that was fine; I updated it and my module's source code now works with both versions. Sure, it's a pain in the butt to always have to check my module's compatiblity with each new release of XEmacs, but that's the price to pay for an active ongoing project (in my case, a research project at a university). BTW, you can't force modules to be completely in Lisp when attaching legacy code written in another language (C, C++) to XEmacs. XEmacs ability to call into C is good enough. It's not a bad thing to write plug-ins in C or C++ -- just a different source language. If you want to write a foreign function interface to ELisp, that wouldn't be a bad idea; it'd be hard, but not a horrible idea. Perhaps the SWIG project team could be persuaded to implement it... Andrew Begel On Friday, December 14, 2001, at 10:31 PM, Stephen J. Turnbull wrote: