Re: emacs-dynamic-module in Emacs Git?

[Ted Zlatanov <tzz@lifelogs.com>]

On Mon, 01 Dec 2014 16:42:07 -0600 Stephen Leake <stephen_leake@stephe-leake.org> wrote: 

SL> Ted Zlatanov <tzz@lifelogs.com> writes:

>> By API I meant both directions, the module API for registration and
>> metadata, and the Emacs API that modules can use. So I still think a
>> call-only API (only in the direction of calling the module) is best for
>> now, so that .h file is unnecessary.

SL> In my particular case, this will not be useful; I need to call some
SL> ada-mode elisp functions from a compiled parser.

SL> These elisp functions will not be in any .h file, but I will need the
SL> appropriate "funcall" in that .h file.
...
SL> My module will be setting text properties in buffers, based on the
SL> results of parsing the code; it's replacing elisp code that does that
SL> now, which is too slow.

Got it, thanks for explaining.  Yes, that kind of parser will need
tighter integration.

SL> _if_ the module author wants to be somewhat isolated from Emacs changes,
SL> and/or support more than one Emacs version, then they will want to stick
SL> to some stable subset. But I don't think we can define that subset ahead
SL> of time, and it will certainly be a different subset for each module.

From the Emacs core side, it's not fun to have to support internal
details for years because modules are using them. For instance, that
kind of deep integration is very likely to be a blocker for concurrent
threads of execution in the core.

SL> However, previous posts have identified some C functions that should
SL> _not_ be called by modules, so perhaps we need an "module_anti_api.h"
SL> that #defines those to throw a compilation error.

I don't think maintaining such a list is viable, but I could be wrong.

Ted