On 02/13/2015 12:37 AM, Eli Zaretskii wrote:
>> Date: Thu, 12 Feb 2015 18:40:19 -0800
>> From: Paul Eggert <eggert@cs.ucla.edu>
>>
>> This raises another question: what exactly should go into emacs.h?  The more we 
>> put into emacs.h, the more likely plugin compatibility won't survive the 
>> transition from one version of Emacs to the next.
> 
> Right.  emacs.h should include the bare minimum, and each function,
> macro, or variable we put there should have a very good reason for
> being there.
> 
> IOW, we should design the interface between the modules and Emacs, and
> we should do this ASAP, before the status quo forces us to make
> compromises we will be unhappy with down the line.

That's why this whole module effort is misguided and dangerous. With a
CFFI-style approach to loading code dynamically, shared modules don't
need to know anything about Emacs internal structure, so there are no
ABI or source compatibility issues.

I still think a CFFI port would be less work than trying to extract a
stable Emacs internals API that modules can include.