Jan Vroonhof <vroonhof(a)math.ethz.ch> writes in xemacs-beta(a)xemacs.org:
John H Palmieri <John.H.Palmieri.2(a)nd.edu> writes:
> > > Loading image-mode...
> > > Symbol's function definition is void: exec-installed-p
> >
> > That function is in the apel package.
image-mode should really (require 'path-util). Then you would
have
noticed this more directly. IMHO apel is misusing the autoload
feature.
What do you consider fair use of autoloads and what do you consider
misuse? I don't have strong opinions either way on this. One could
argue that autoloads are only for the user, ie. for convenience in
building a .emacs and having M-x some-unloaded-function Do The Right
Thing. On the other hand, I would guess that there is a fair amount
of legacy code that doesn't do explicit requires when it needs
external symbols.
I have a strong preference for *not* putting requires at the
toplevel when only defuns are involved as they aren't strictly
needed for bytecompilation and only slow things down. I *have* a
strong preference for using explicit requires rather than hiding
the dependencies in a bytecompilation lisp package like W3 and
Gnus do.
In my view of the world, one should be able to hand bytecompile
xemacs -batch -f batch-byte-compile some-file.el
any lisp file in the searched load-path and have it work. Currently
it does not.
> Great! Now that I've installed apel, I can see the pictures
without
> any problem. Should the text-modes entry in the package index say
> that it requires 'apel', in addition to ispell, fsf-compat, and
> xemacs-base?
The theory would be that apel would have an provide 'path-util
line
so you could resolve the require 'path-util using that database.
Currently XEmacs only does this for major modes and even there it
doesn't really work yet (as provides lines for most packages are not
complete).
We ought to make this a project for the (very) near future. I've
already done it with everything we have direct control over in
xemacs-base, xemacs-devel, etc.