Eli Zaretskii writes: >> From: Stefan Monnier >> Date: Fri, 13 Feb 2015 14:11:33 -0500 >> Cc: Paul Eggert , emacs-devel@gnu.org >> >> > I would start by coming up with the minimum set of requirements a >> > module needs to be able to communicate with Emacs. >> >> Easy: take the existing sample modules and see what they need. > > No one seems to care, so I will bite the bullet. I took a stab at creating emacs_module_api.h; attached. To do this, I replaced "#include " in modules/curl/curl.c with "#include ", and copied stuff from lisp.h and other headers to emacs_module_api.h until it compiled. Note the FIXMEs; I could not figure out what was going on in some places, so I just kludged it for now. I don't know if this is useful, but it is my interpretation of what Stefan proposed; lisp.h would "#include emacs_modules_api.h". (He called it "emacs.h", but I think including 'modules' in the name is better). > The below is based > on looking at the modules branch. > > It looks like modules need: > > . A function to replace the DEFUN macro and the related defsubr call. > > . Some definition of Lisp_Object > > This already presents at least 2 problems. The first is 32- vs > 64-bit issues. We need some way of checking that a 32-bit module > isn't loaded by a 64-bit Emacs, and vice versa. Good point. That's a special case of "don't load a module compiled for processor X in an Emacs compiled for processor Y". gnu binutils has facilities for that. > The other problem is more serious: Emacs can be built with or > without --check-lisp-object-type, and with or without --wide-int; > how will the module know which implementation to use? Similar check when the module is loaded. Which means we need some metainfo for each module, and a standard function to retrieve it. > . Functions to access values of Lisp objects. We shouldn't rely on C > macros like XINT and XWINDOW for that, because macros track too > closely the internals of each object. So I propose to use > functions that will be exposed via the API. If we follow Stefan's suggestion, then either this function approach is not viable, or we need another #ifdef for module vs emacs. > The above means that most of the C source files under modules/ should > be thoroughly rewritten. Yes. > They are currently written as if the code were an integral part of > Emacs on one of the Emacs C files. Going that way means that modules > will have to be recompiled from sources for each Emacs version, and > practically will have to live in the Emacs tree. Maybe this is what we > want, I don't know. This is the model I had in mind. Since I need max speed with mixed Ada/lisp code, I need tight integration with the core. The people who need that speed for Ada mode will simply have to recompile the module for each Emacs release; they are coders, so that's not a problem. On the other hand, modules for other use cases (I have in mind a spam filter for Gnus) would not need to be nearly so tightly bound, so a more limited/safe API would be appropriate. Rather than splitting out emacs_module_api.h from lisp.h, we could add __declspec(dllexport) to a subset of the functions in lisp.h; I suspect that will be a small number. I'll give that a try next. Is there an equivalent on Linux (I don't recall ever seeing one)? -- -- Stephe