emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Achim Gratz <Stromeko@nexgo.de>
To: emacs-orgmode@gnu.org
Subject: missing autoloads / (void-variable org-version)
Date: Thu, 26 Apr 2012 07:52:59 +0200	[thread overview]
Message-ID: <87vcknm43o.fsf@Rainer.invalid> (raw)

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

             reply	other threads:[~2012-04-26  5:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-26  5:52 Achim Gratz [this message]
2012-04-26 10:23 ` missing autoloads / (void-variable org-version) Sebastien Vauban
2012-04-26 16:06   ` Achim Gratz
2012-04-26 19:30     ` Sebastien Vauban
2012-04-26 22:03       ` Bastien
2012-04-26 22:04       ` Bastien
2012-04-26 11:55 ` Detlef Steuer
2012-04-26 12:01 ` Martyn Jago
2012-04-26 16:14   ` Achim Gratz
2012-04-26 13:15 ` Bastien
2012-04-26 19:03   ` Achim Gratz
2012-04-26 21:54     ` Bastien
2012-04-29  9:53       ` Michael Sperber
2012-04-29 18:57         ` Achim Gratz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87vcknm43o.fsf@Rainer.invalid \
    --to=stromeko@nexgo.de \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).