From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: missing autoloads / (void-variable org-version) Date: Thu, 26 Apr 2012 07:52:59 +0200 Message-ID: <87vcknm43o.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:53781) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNHdl-0004AM-NI for emacs-orgmode@gnu.org; Thu, 26 Apr 2012 01:53:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SNHdj-0001Uy-Fn for emacs-orgmode@gnu.org; Thu, 26 Apr 2012 01:53:17 -0400 Received: from plane.gmane.org ([80.91.229.3]:37043) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNHdj-0001Uk-5u for emacs-orgmode@gnu.org; Thu, 26 Apr 2012 01:53:15 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SNHdg-0004tF-FI for emacs-orgmode@gnu.org; Thu, 26 Apr 2012 07:53:12 +0200 Received: from pd9eb58eb.dip.t-dialin.net ([217.235.88.235]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Apr 2012 07:53:12 +0200 Received: from Stromeko by pd9eb58eb.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Apr 2012 07:53:12 +0200 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 Since my Makefile branch was merged I've been getting flak for breaking certain setups. Now, the change didn't actually break them, but I did make (perhaps foolishly) a deliberate decision to make that particular breakage fatal rather than silent. It would be very easy to continue to paper over the breakage and pretend things are working when they're not. What irritates me greatly is that quite a few of the people that insist on this "solution" are the ones who would have to deal with the Heisenbugs thus introduced. So let me explain once more what is broken: Consider a core emacs library "test", consisting of the main "test.el" and auxiliary functions in "test-aux.el". The main entry points are in "test.el" and thus you'd "(require 'test)" in your .emacs to activate the package. The auxiliary functions are not needed in "test.el", so to make them available to the user or whatever function that needs to call them, these entry points are autoloaded (let's say the only function there is "test-aux"). When this package gets installed into emacs, the autoload forms will be extracted into "loaddefs.el" in the main lisp directory. You can then call "(test-aux)" without having to explicitly load "test-aux.el", since the autoload form has registered that association and will load "test-aux.el" automatically when encountering the first use of the function test-aux. Now the development version of this same package gets installed locally. The load-path is altered so that emacs finds the development version first. Thus "(require 'test)" will load the development version. If you now try to "(test-aux)", what happens? Autoload still has all the associations from "loaddefs.el" and thus tries to load "test-aux.el", which will end up finding the file in the development version. So all is well, right? Development progresses and as "test.el" grows larger some functions are moved to "test-extra.el". Also, "test-aux.el" is split into "test-aux1.el", while the function test-aux (yes, the same name as the old, but with different arguments) is moved to "test-aux2.el". The functions in "test-extra.el" become unavailable since autoload doesn't know about them — unless you explicitely load "test-aux.el" of course. Also, the calls to "(test-aux)" flip-flop between calling the old and new test-aux: if that call is made before a load of "test-aux2.el", emacs will look for it in "test-aux.el" and only find that file in its own install directory. If you happened to have loaded "test-aux2.el" (maybe due to a "(require 'test-aux2)" in "test-extra.el"), then the new definition of "(test-aux)" will be used. So you will have irritated users and developers alike and bugs that don't reproduce (or only with certain versions of emacs that happen to have specific versions of library test integrated). The real solution of course is to re-generate the autoloads file for the development version and explicitely load it, say "(require 'test-install)". That still leaves an open flank if you delete both a function and it's associated source file from the development version: if someone then uses "(test-deleted-function)", the autoload definition in Emacs will happily find the stale source it has installed since it is not shadowed anymore by the same file in the development version. I've no idea yet if that is fixable without touching the actual installation and how difficult it would be, but that's a minor worry at this point. If you've made it here, please weigh in on whether you want to have things correctly fixed or simply papered over. Either one is fine with me... Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada