[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Opening (for the first time) a 10-line Org doc takes 4 seconds

From: Achim Gratz
Subject: Re: [O] Opening (for the first time) a 10-line Org doc takes 4 seconds
Date: Wed, 19 Dec 2012 16:09:20 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.91 (gnu/linux)

Bastien writes:
>> (if (locate-library "org-loaddefs")
>>     (require 'org-loaddefs)
>                ^^^^^^^^^^^^^
> You don't need this, there is (load "org-loaddefs.el" t t) in org.el.

Well, yes he does when he is using Org from Git.  It's a wash when he's
using builtin Org from Emacs and potentially wrong when he's using Org
from ELPA, depending on if he does it before or after

You've expressed before that you want to know why this is so.  As a
reminder, Org from Git currently has all its autoload definitions in
org-loaddefs.  Lets look at this for all possible Emacs versions:

XEmacs and Emacs 22 don't come with a builtin Org version.  You have no
autoloads including none for the entry point for the major mode until
you load org-loaddefs (or org).

Emacs 23, 24.1 and 24.2 comes with older versions of Org that don't even
have org-loaddefs.  All autoloads for the builtin version are in
loaddefs from Emacs and they are already loaded when the user
initialization stuff is run.  Some things in those autoloads happen to
point to the correct libraries, but only by chance.  Generally one has
to assume that the autoloads that are present have the wrong docstring,
point to the wrong file and present an outdated API.  To fix this, one
must load org-loaddefs (or org).

Emacs 24.3 will come with a newer version of Org, but still older than
the one from Git.  Only part of the autoloads are present in loaddefs,
the rest would be pulled in from the bundled org-loaddefs when org is
loaded.  That is the reason why one does not need to do that when only
using the builtin Org version.  Again however, these builtin autoload
definitions from loaddefs must be presumed outdated for Org from Git, so
it is still necessary to load org-loaddefs (or org) in the initalization
code to make sure the correct first-level autoloads take precedence even
when it is assured that all autoload code-paths also trigger loading of
org (I don't think that this can be easily guaranteed and I know of no
tool that would allow one to analyse).

Last but not least, if one uses Org from ELPA, then it must be arranged
that org-loaddefs gets loaded only after package-initialize, otherwise
you'll end up with the correct first-level autoloads, but outdated
second-level autoloads (that get replaced with the current ones when org
gets loaded).

+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]