From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Question Date: Fri, 02 Jul 2010 20:45:38 +0900 Message-ID: <877hlexg2l.fsf@uwakimon.sk.tsukuba.ac.jp> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1278071441 28134 80.91.229.12 (2 Jul 2010 11:50:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 2 Jul 2010 11:50:41 +0000 (UTC) Cc: Dan Davison , Eric Schulte , Emacs developers To: Carsten Dominik Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 02 13:50:38 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OUelP-00051D-P7 for ged-emacs-devel@m.gmane.org; Fri, 02 Jul 2010 13:50:37 +0200 Original-Received: from localhost ([127.0.0.1]:50164 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OUelK-0005wc-VK for ged-emacs-devel@m.gmane.org; Fri, 02 Jul 2010 07:50:30 -0400 Original-Received: from [140.186.70.92] (port=55872 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OUelE-0005wP-R2 for emacs-devel@gnu.org; Fri, 02 Jul 2010 07:50:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OUelD-0006v9-8B for emacs-devel@gnu.org; Fri, 02 Jul 2010 07:50:24 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:45194) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUelD-0006uV-06 for emacs-devel@gnu.org; Fri, 02 Jul 2010 07:50:23 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id CC11D1535AE; Fri, 2 Jul 2010 20:50:19 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 343181A291A; Fri, 2 Jul 2010 20:45:38 +0900 (JST) In-Reply-To: X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" a03421eb562b XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:126692 Archived-At: Carsten Dominik writes: > For supporting different languages, we will have a few emacs lisp > files which should not be compiled because the have dependencies on > code that is not present in Emacs. I.e. they do something like > > (require 'slime) This is not a problem, unless it's within `eval-when-compile'. Go ahead and compile it otherwise. > and call lots of functions from this package. For *functions*, this isn't a problem, either. However, *macros* from the slime library must be defined at compile time, because Emacs byte code doesn't know how to expand and reevaluate macros. (IIRC, anyway, for sure XEmacs's bytecode interpreter can't do that.) Instead, the macro is expanded, then the expansion is compiled at compile time. > I think the best way it to leave these files uncompiled. I feel sick ... ok, it got better. No, this is rarely a good idea. If you have only functions, it's pointless. If you have macros, then remember that macros get evaluated twice: once to generate code, and once to evaluate the generated code. The function that generates the expansion is rarely very efficient because it is expected to be expanded once at compile time. Instead it is normally written to be as straightforward an expression of the desired expansion code as possible. IOW, you're likely to impose a perceptible performance hit on those users. Since org-mode is now part of Emacs, third party packages can assume it will be available, and if leaving files uncompiled seems your only option, then it's probably best all-around to contribute that code to the third-party package, and have it compiled there.