sb> Michael Sperber <sperber(a)informatik.uni-tuebingen.de&gt; writes in xemacs-beta(a)xemacs.org: sb> Packages typically want to know two specific things about the external sb> environment. sb> 1. They want to know where their own source code is so they can sb> add the directory to the load-path. This is irrelevant in the sb> current design as long as the package gets installed into a sb> proper directory, this part is automatically taken care of. sb> 2. They want to know where their data files are. The programming sb> interface for this is `locate-data-directory', `locate-data-file' sb> and 'locate-data-directory-list'. sb> Some packages need to know a third thing and that is where their sb> associated scripts or helper binaries are located in order to execute sb> them directly, or to add them to the exec-path. This has only been sb> partially addressed, but everything works so long as scripts are put sb> into the proper place (currently lib-src). Exactly right. There is a problem currently with associated executables: you really want only the package, which knows about its executables, to be able to execute them. You don't want to add them to exec-path and PATH where potentially everyone gets affected. This is also a great source of confusion currently, for example with the tm-associated scripts. sb> As far as a programming API goes, the only item that is important is sb> #2, #1 and #3 should be handled automagically and correctly by sb> packaging support code in XEmacs and thus should be ignored by a sb> package, ie. a Lisp package on XEmacs can *always* assume that sb> 1. It's source code is in the load-path; and 2. It's helper scripts sb> and binaries are in the exec-path. I think especially this last bit will have to change: I would want a package to identify itself (implicitly or explicitly) when asking for the location of its associated files. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla