public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
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


             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