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.