Re: [O] missing autoloads / (void-variable org-version)

[Sebastien Vauban]

Hi Achim,

Achim Gratz wrote:
> 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:

Did not know that term... Thanks.

http://en.wikipedia.org/wiki/Heisenbug

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

Here, I would have thought that invoking the function `text-aux' would open
the "production" Lisp file (that is, the one in Emacs code base) as you use
Emacs loaddefs.el associations, no?

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

I've experienced enough couple of hours lost in the past, searching for
problems due to mixed versions loaded, to know what the correct answer is.

Often, such problems are even not detectable in such a case:

1. some function loads an Org function (without you being aware), hence the
   Emacs Org version.

2. you update your load-path to point to Org latest dev version (.. but not at
   the very top of your Emacs init file).

3. you load other Org components.

4. you have problems.

5. you don't notice them by inspecting `load-path' variable: your Org dev
   directory is in front of Emacs Org directory, letting you think everything
   is correct!

Best regards,
  Seb

-- 
Sebastien Vauban