From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: emacs-dynamic-module in Emacs Git? Date: Mon, 01 Dec 2014 14:12:08 -0500 Message-ID: References: <87k32sh50f.fsf@lifelogs.com> <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1417461195 29356 80.91.229.3 (1 Dec 2014 19:13:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Dec 2014 19:13:15 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 01 20:13:08 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 1XvWPC-0006Sf-EM for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2014 20:13:06 +0100 Original-Received: from localhost ([::1]:33445 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvWP9-00037Q-UI for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2014 14:13:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54841) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvWP0-000374-9Y for emacs-devel@gnu.org; Mon, 01 Dec 2014 14:13:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XvWOs-0007CD-RC for emacs-devel@gnu.org; Mon, 01 Dec 2014 14:12:54 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:42942) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvWOs-0007Bw-Mz for emacs-devel@gnu.org; Mon, 01 Dec 2014 14:12:46 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUIAGA2ZVRMCqTq/2dsb2JhbABbgw6KYssMBAICgRwXAQEBAQEBfIQDAQEDAVYoCws0EhQYDYhvCdEELIp4hiMWhDUFjAuTWpEpghSBdoQaH4J7AQEB X-IPAS-Result: AsUIAGA2ZVRMCqTq/2dsb2JhbABbgw6KYssMBAICgRwXAQEBAQEBfIQDAQEDAVYoCws0EhQYDYhvCdEELIp4hiMWhDUFjAuTWpEpghSBdoQaH4J7AQEB X-IronPort-AV: E=Sophos;i="5.07,380,1413259200"; d="scan'208";a="99274951" Original-Received: from 76-10-164-234.dsl.teksavvy.com (HELO pastel.home) ([76.10.164.234]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Dec 2014 14:12:18 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 72AFC86B6; Mon, 1 Dec 2014 14:12:08 -0500 (EST) In-Reply-To: (Ted Zlatanov's message of "Mon, 01 Dec 2014 10:36:10 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:178626 Archived-At: > 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. The exported functions will need to take Lisp_Object arguments and return Lisp_Object values, so they need to be able to test&create Lisp_Objects, hence they need to make calls to Emacs's C code even for the most trivial module imaginable. > I agree with the rest of your comments, except that it's not clear when > you'll feel that the module loading is settled enough to merge into the > master branch. The criteria for me is not whether the feature is ready for general use, but whether the code that needs to be merged is sufficiently clean and stable ("stable" in the sense that it probably won't need to be completely replaced by a different implementation, so future changes should be "incremental improvements"). The current code can pretty much be merged as it is. Stefan