Re: /srv/bzr/emacs/trunk r110286: Sync Org 7.9.2 from the commit tagged "release_7.9.2" in Org's Git repo.

[Achim Gratz <Stromeko@nexgo.de>]

Bastien writes:
>> It's weird to see this as a constant (rather than something related to
>> the installation prefix), since it won't be correct for many
>> installations (but I did not check how it is actually used):

This is a generated file in Org and the path generated is related to the
installation prefix.  Not sure how this should be handled in Emacs.

Reminds me: the file local variable that say "version control: never"
should also be deleted from that file.

>> ;;;###autoload
>> (defconst org-odt-data-dir "/usr/share/emacs/etc/org"
>>   "The location of ODT styles.")
>
> This is not only weird, this is wrong.  I fixed this in Org,
> this will be part of the next bugfix sync with Emacs.

Huh?  How is a defvar any different than a defconst?  The problem is not
the defconst as such.

>> Also, have you considered having a separate org-loaddefs.el, for
>> autoloads that are not relevant until org.el is loaded?
>
> Yes, I can how loaddefs.el could benefit from an org-loaddefs.el.
>
> I see how I can generate a separate org-loaddefs.el (and we do this
> already for people who install Org separately, the file is called
> org-install.el) but I don't see how I can prevent Emacs from adding
> the same autoloaded functions in loaddefs.el.

You change all autoload cookies to some different value like
autoload-org.  Then you generate org-loaddefs.el using that cookie and
when loaddefs.el is generated using the original cookie it comes up
empty.  The real work there is to decide, for each autoload, whether it
belongs into org-loaddefs.el or loaddefs.el.  This is decidedly not the
same thing that org-install.el does.


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

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves