From: Matthew Kennedy <mkennedy@gentoo.org>
To: gentoo-dev@gentoo.org
Cc: usata@gentoo.org, jbms@gentoo.org
Subject: [gentoo-dev] (emacs) proposed site-lisp and byte-compilation improvements
Date: Sun, 16 Nov 2003 17:33:14 -0600 [thread overview]
Message-ID: <87r807c2it.fsf@killr.ath.cx> (raw)
Hi,
I'd like to get a discussion going about possible improvements to
GNU Emacs on Gentoo. If you got CCed make sure to reply to the
list. Here are some ideas I've had.
* Firstly, please review this:
http://dev.gentoo.org/~mkennedy/emacs/site-gentoo.el-rfc.txt
I would like to see us move to something like the above for
customization.
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.
* Byte-Compile site-gentoo.el and all site hooks
Perhaps this will make for more rapid load times.
* Install elisp source in such a way that global recompilation is
possible.
It is a "dirty little secret" that our .elc files from add-on elisp
packages are able to persist between emacs major and minor version
upgrades. The format of byte-compilation can change between releases,
and allowing these old .elc files to be loaded into an updated emacs
can cause it to crash.
I suggest we provide a way to recompile all .el files for elisp add-on
packages (typically from the app-emacs/ category, but also from
ebuilds supporting the emacs USE flag). This mechanism should be
called whenever a new emacs upgrade is performed.
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.
* 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).
* Your Thoughts Here...
Matt
--
Matthew Kennedy
Gentoo Linux Developer
--
gentoo-dev@gentoo.org mailing list
next reply other threads:[~2003-11-16 23:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-16 23:33 Matthew Kennedy [this message]
2003-11-17 0:29 ` [gentoo-dev] (emacs) proposed site-lisp and byte-compilation improvements Spider
2003-11-17 1:26 ` Jeremy Maitin-Shepard
2003-11-17 15:40 ` [gentoo-dev] " Mamoru KOMACHI
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r807c2it.fsf@killr.ath.cx \
--to=mkennedy@gentoo.org \
--cc=gentoo-dev@gentoo.org \
--cc=jbms@gentoo.org \
--cc=usata@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox