From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: emacs-dynamic-module in Emacs Git? Date: Mon, 01 Dec 2014 20:16:58 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87zjb6sved.fsf@lifelogs.com> References: <85tx1rg64e.fsf_-_@stephe-leake.org> <87siha7r3b.fsf@lifelogs.com> <87lhmz4mtj.fsf@lifelogs.com> <87sih575rc.fsf@lifelogs.com> <8361dyaqf1.fsf@gnu.org> <837fycae5p.fsf@gnu.org> <87y4qs19mi.fsf@lifelogs.com> <874mtfu0et.fsf@lifelogs.com> <85a937m1q8.fsf@stephe-leake.org> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1417483007 12460 80.91.229.3 (2 Dec 2014 01:16:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Dec 2014 01:16:47 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 02 02:16:41 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xvc51-0007hl-Jh for ged-emacs-devel@m.gmane.org; Tue, 02 Dec 2014 02:16:39 +0100 Original-Received: from localhost ([::1]:34717 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xvc51-00019L-1j for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2014 20:16:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43137) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xvc4t-00019B-5u for emacs-devel@gnu.org; Mon, 01 Dec 2014 20:16:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xvc4n-00026Y-Qn for emacs-devel@gnu.org; Mon, 01 Dec 2014 20:16:31 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:44421) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xvc4n-00026G-L1 for emacs-devel@gnu.org; Mon, 01 Dec 2014 20:16:25 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Xvc4m-0007d8-Iq for emacs-devel@gnu.org; Tue, 02 Dec 2014 02:16:24 +0100 Original-Received: from c-98-229-61-72.hsd1.ma.comcast.net ([98.229.61.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 02 Dec 2014 02:16:24 +0100 Original-Received: from tzz by c-98-229-61-72.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 02 Dec 2014 02:16:24 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 39 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-98-229-61-72.hsd1.ma.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:TYm56UZ4wy5MqLCKTfzaEv2y0pw= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:178662 Archived-At: On Mon, 01 Dec 2014 16:42:07 -0600 Stephen Leake wrote: SL> Ted Zlatanov 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