On 6/5/2000 7:48 PM, Ben Wing at ben(a)666.com wrote:
this is not really a good idea. the basic problem here is that the
xemacs
developers would like to have freedom to change the internal api whenever they
want, and this becomes problematic with random code around that might use any
function.
what i'd rather happen is to provide a limited api to modules, principally to
allow them access to the allocation system, and then provide a specific
function
that they can use to call Lisp functions, including primitives defined in C.
global variables should for the most part not be exported at all; with the
proper higher-level functions, this should be mostly unnecessary in any case.
would you be interested in helping design such an api?
I understand why that'd be a bad thing. I don't have time to work on this
kind of API (for my purposes, I can just export the symbols I need), though
I can imagine what it could need pretty easily.
Actually, my latest project points to another area where the current
mechanism is unsuitable for extension: the WndProc for XEmacs under Windows.
I needed to add some callbacks for a project I'm working on, but there's no
mechanism to extend the switch statement in the MSW wndproc found in
event-msw.c. There should be a way to add tags into here (through some
event-hook mechanism) so extensions can do things at event-handling time
without directly modifying this code in the XEmacs source.
Andrew