Matthew Kennedy <[EMAIL PROTECTED]> writes:
> In no particular order, here are some other changes I propose:
> * Move away from the big concatenation of
> /usr/share/emacs/site-lisp/*-gentoo.el into
> /usr/share/site-lisp/site-start.el.
> Instead, leave site-start.el alone, and create a site-gentoo.el which
> loads each *-gentoo.el file (call these "site hooks") pragmatically.
> This has the benefit of freeing up site-start.el for user usage. The
> programmatic approach also allows for the possibility of the user
> defining their own site hooks.
I think this is a good idea. I think though that we need a more
explicit policy about what should be placed in these site initialization
files. Specifically, things such as a (bbdb-initialize) and other such
things in the site init files worry me. Perhaps we should have several
different levels of initialization files. For example, we could have
one file (per package) that only sets the load path and specifies
autoloads. We could even provide in elisp-common.eclass a system for
generating such load path and autoload specifications (rather than
requiring that a separate file be included in the files directory).
Then, for each package there can be another site initialization file
that does additional things, like actually load certain packages (or in
the case of bbdb, initialize it). It might be useful to also create a
/etc/skel/.emacs.el and a default.el that loads site-gentoo.el.
> * Byte-Compile site-gentoo.el and all site hooks
> Perhaps this will make for more rapid load times.
Good idea.
> * Install elisp source in such a way that global recompilation is
> possible.
Good idea. Perhaps we can just do:
find /usr/share/emacs/site-lisp -name \*.el -exec emacs -batch -f \
batch-byte-compile ... {} \;
> We should probably keep a separate source archive directory somewhere
> so we can compile for multiple emacs implementations
> (eg. app-editors/emacs and app-editors/emacs-cvs). We should take
> whatever steps are necessary to ensure find-function/variable/library
> etc. still work properly.
Maybe /var/cache/site-lisp/<emacs-version>
> * emacs and emacs-cvs coexistence
> Following on from the previous point, it would be nice to clean up
> app-editors/emacs and app-editors/emacs-cvs so they co-exist more
> cleanly. (provide and /usr/bin/emacs and a /usr/bin/emacs-cvs -- I
> know there's already a version number symlink there).
This seems like a more general problem, that affects many packages. I
suppose it nonetheless has to be solved for each package individually.
I suppose we could have /usr/bin/emacs-version and /usr/bin/emacs as a
symlink to the most recently installed version. Or maybe create an
emacs-config tool that allows the system admin and each user to select
the desired version.
As far as such a tool, I think we should also provide tools for
regenerating site-lisp.el (or site-gentoo.el) and the various other
files that will be generated in the new system. Additionally, if we
change the system for byte compiling, we should provide a tool to
re-byte compile the packages. This could all go in an elisp-config
package.
--
Jeremy Maitin-Shepard
--
[EMAIL PROTECTED] mailing list
