all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Carsten Dominik <carsten.dominik@gmail.com>
To: Stephen J. Turnbull <stephen@xemacs.org>
Cc: Dan Davison <davison@stats.ox.ac.uk>,
	Eric Schulte <schulte.eric@gmail.com>,
	Emacs developers <emacs-devel@gnu.org>
Subject: Re: Question
Date: Sat, 3 Jul 2010 07:38:44 +0200	[thread overview]
Message-ID: <5007B929-B759-4728-9BE0-E2DAEACA7509@gmail.com> (raw)
In-Reply-To: <877hlexg2l.fsf@uwakimon.sk.tsukuba.ac.jp>

OK, thanks for the input everyone.

We'll think about and implement appropriate solutions.
Looking at the files again, I actually think that we can make
them compile with a small number of declare-function statements.

Thanks!

- Carsten

On Jul 2, 2010, at 1:45 PM, Stephen J. Turnbull wrote:

> 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.
>







  reply	other threads:[~2010-07-03  5:38 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-02  4:15 Question Carsten Dominik
2010-07-02  9:28 ` Question Juanma Barranquero
2010-07-02  9:57 ` Question Lennart Borgman
2010-07-02 11:45 ` Question Stephen J. Turnbull
2010-07-03  5:38   ` Carsten Dominik [this message]
2010-07-02 12:39 ` Question Richard Stallman
2010-07-02 13:27   ` Slime Harald Hanche-Olsen
2010-07-02 13:35     ` Slime Chong Yidong
2010-07-02 15:58       ` Slime Helmut Eller
     [not found] <20191110031420.yosogxfr6kgrctwn.ref@Ergus>
2019-11-10  3:14 ` Question Ergus
2019-11-10  4:51   ` Question Stefan Monnier
2019-11-10  8:07   ` Question Andreas Schwab
2019-11-10  9:06     ` Question João Távora
  -- strict thread matches above, loose matches on Subject: below --
2006-08-01 22:04 question A Soare
2006-08-02  6:13 ` question David Kastrup
2006-08-02  6:35   ` question Nick Roberts
2006-08-02  6:54     ` question David Kastrup
2006-08-02 21:20       ` question Richard Stallman
2006-08-02  9:45 ` question Thien-Thi Nguyen
2006-07-28 13:05 question A Soare
2006-07-28 19:38 ` question Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5007B929-B759-4728-9BE0-E2DAEACA7509@gmail.com \
    --to=carsten.dominik@gmail.com \
    --cc=davison@stats.ox.ac.uk \
    --cc=emacs-devel@gnu.org \
    --cc=schulte.eric@gmail.com \
    --cc=stephen@xemacs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.