| 1 |
Matthew Kennedy <mkennedy@g.o> writes: |
| 2 |
> In no particular order, here are some other changes I propose: |
| 3 |
|
| 4 |
> * Move away from the big concatenation of |
| 5 |
> /usr/share/emacs/site-lisp/*-gentoo.el into |
| 6 |
> /usr/share/site-lisp/site-start.el. |
| 7 |
|
| 8 |
> Instead, leave site-start.el alone, and create a site-gentoo.el which |
| 9 |
> loads each *-gentoo.el file (call these "site hooks") pragmatically. |
| 10 |
> This has the benefit of freeing up site-start.el for user usage. The |
| 11 |
> programmatic approach also allows for the possibility of the user |
| 12 |
> defining their own site hooks. |
| 13 |
|
| 14 |
I think this is a good idea. I think though that we need a more |
| 15 |
explicit policy about what should be placed in these site initialization |
| 16 |
files. Specifically, things such as a (bbdb-initialize) and other such |
| 17 |
things in the site init files worry me. Perhaps we should have several |
| 18 |
different levels of initialization files. For example, we could have |
| 19 |
one file (per package) that only sets the load path and specifies |
| 20 |
autoloads. We could even provide in elisp-common.eclass a system for |
| 21 |
generating such load path and autoload specifications (rather than |
| 22 |
requiring that a separate file be included in the files directory). |
| 23 |
Then, for each package there can be another site initialization file |
| 24 |
that does additional things, like actually load certain packages (or in |
| 25 |
the case of bbdb, initialize it). It might be useful to also create a |
| 26 |
/etc/skel/.emacs.el and a default.el that loads site-gentoo.el. |
| 27 |
|
| 28 |
> * Byte-Compile site-gentoo.el and all site hooks |
| 29 |
|
| 30 |
> Perhaps this will make for more rapid load times. |
| 31 |
|
| 32 |
Good idea. |
| 33 |
|
| 34 |
> * Install elisp source in such a way that global recompilation is |
| 35 |
> possible. |
| 36 |
|
| 37 |
Good idea. Perhaps we can just do: |
| 38 |
find /usr/share/emacs/site-lisp -name \*.el -exec emacs -batch -f \ |
| 39 |
batch-byte-compile ... {} \; |
| 40 |
|
| 41 |
> We should probably keep a separate source archive directory somewhere |
| 42 |
> so we can compile for multiple emacs implementations |
| 43 |
> (eg. app-editors/emacs and app-editors/emacs-cvs). We should take |
| 44 |
> whatever steps are necessary to ensure find-function/variable/library |
| 45 |
> etc. still work properly. |
| 46 |
|
| 47 |
Maybe /var/cache/site-lisp/<emacs-version> |
| 48 |
|
| 49 |
> * emacs and emacs-cvs coexistence |
| 50 |
|
| 51 |
> Following on from the previous point, it would be nice to clean up |
| 52 |
> app-editors/emacs and app-editors/emacs-cvs so they co-exist more |
| 53 |
> cleanly. (provide and /usr/bin/emacs and a /usr/bin/emacs-cvs -- I |
| 54 |
> know there's already a version number symlink there). |
| 55 |
|
| 56 |
This seems like a more general problem, that affects many packages. I |
| 57 |
suppose it nonetheless has to be solved for each package individually. |
| 58 |
I suppose we could have /usr/bin/emacs-version and /usr/bin/emacs as a |
| 59 |
symlink to the most recently installed version. Or maybe create an |
| 60 |
emacs-config tool that allows the system admin and each user to select |
| 61 |
the desired version. |
| 62 |
|
| 63 |
As far as such a tool, I think we should also provide tools for |
| 64 |
regenerating site-lisp.el (or site-gentoo.el) and the various other |
| 65 |
files that will be generated in the new system. Additionally, if we |
| 66 |
change the system for byte compiling, we should provide a tool to |
| 67 |
re-byte compile the packages. This could all go in an elisp-config |
| 68 |
package. |
| 69 |
|
| 70 |
-- |
| 71 |
Jeremy Maitin-Shepard |
| 72 |
|
| 73 |
-- |
| 74 |
gentoo-dev@g.o mailing list |
Archives