From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: Web site bug Date: Mon, 29 Oct 2012 08:29:14 +0100 Message-ID: <877gq9wxbp.fsf@Rainer.invalid> References: <5088513F.7000202@gmx.de> <87k3ufwkyr.fsf@bzg.ath.cx> <508AEB33.8050205@gmx.de> <871ugks721.fsf@bzg.ath.cx> <80d304gur0.fsf@somewhere.org> <87hapgnv18.fsf@bzg.ath.cx> <87625vhwu6.fsf@Rainer.invalid> <87a9v6khyn.fsf@bzg.ath.cx> <871ugiinj1.fsf@Rainer.invalid> <87objllq8x.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:43177) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TSjmw-00076x-NW for emacs-orgmode@gnu.org; Mon, 29 Oct 2012 03:29:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TSjmv-0006fD-9Y for emacs-orgmode@gnu.org; Mon, 29 Oct 2012 03:29:34 -0400 Received: from plane.gmane.org ([80.91.229.3]:51555) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TSjmv-0006ea-2w for emacs-orgmode@gnu.org; Mon, 29 Oct 2012 03:29:33 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TSjn0-0000ya-2g for emacs-orgmode@gnu.org; Mon, 29 Oct 2012 08:29:38 +0100 Received: from pd9eb4ae9.dip.t-dialin.net ([217.235.74.233]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Oct 2012 08:29:38 +0100 Received: from Stromeko by pd9eb4ae9.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Oct 2012 08:29:38 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Bastien writes: > Can you point at an actual reproducible and simple bug with > the current way Org defines autoloads? After the introduction of org-loaddefs, the autoloads should be extracted into two files and only the first is supposed to be loaded before org is actually used and the second, org-loaddefs, is supposed to be loaded by Org itself. But when using a standalone Org, that first file doesn't exist and there's no mechanism for the generated autoloads (all in org-loaddefs) to be loaded before Org is used. You suggest that in a standalone installation the user doesn't need to do anything by way of customization: that's a bug, because the autoloads in org-loaddefs for the standalone Org are not present _at all_ in that situation. That there may be some autoloads present from another Org version (from Emacs) that by accident may point to a file that will then cause Org to be loaded anyway doesn't make this bug go away. Standalone Org needs a file separate from org-loaddefs to collect the autoload definitions into that will be loaded on startup. For Emacs, this is loaddefs; for package manager, this is org-autoloads; for Org standalone, I posit that we should keep org-install. If we keep a different system of how to handle autoloads depending on the type of installation, then it will be impossible to test that everything works correctly[1], not to mention the confusion that this discussion so amply demonstrates. [1] For instance, any first-level autoloaded function that somehow calls into these files: ob, ob-keys, ob-lob, ob-tangle, org-archive, org-ascii, org-attach, org-bbdb, org-clock, org-datetree, org-docbook, org-element, org-exp, org-feed, org-footnote, org-freemind, org-html, org-icalendar, org-id, org-indent, org-irc, org-latex, org-lparse, org-mobile, org-odt, org-plot, org-publish, org-remember, org-table, org-taskjuggler, org-timer, org-xoxo needs to make sure that org-loaddefs has been loaded, which currently only happens in org, but I have not been able to ascertain that each codepath to one of these functions will actually go through it. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds