neitzel@infbs.UUCP (Martin Neitzel) (05/18/89)
In gnu.emacs, David C Lawrence (tale@pawl.rpi.edu) recently brought up the topic "integretation of contributed elisp code". To dig right into the midst: dl> So how do we convince RMS to include some of this stuff in the dl> distribution? Just ask? (Somewhat novel idea for me; I dl> haven't tried it.) Petition? I, for one, would like to see dl> it be included in the regular distribution. dl> So the question remains: how do we get it sanctioned? I couldn't agree more. The handling of ``contributed software'' is becoming more and more difficult, especially if it concerns replacements for officially distributed stuff. Keeping up with the submissions to comp.emacs and gnu.emacs alone, caring about a simple index file with short descriptions etc. has become a full time job. In analogy to the X-consortium, I would like to see some kind of (visible & addressable) "elisp consortium" established, that cares about the composition of the emacs "core" distribution. The "some-kind-of-emacs-consortium" should - evaluate suggested changes. - accept those "petitions" and organize votings. - identify and minimize reduncy in the core. - act as mediator to the "distributor in charge" (probably RMS & friends) This work requires much knowledge of and experience with the existing lisp stuff. To summarize: How about a newsgroup gnu.emacs.core? Martin
cks@white.toronto.edu (Chris Siebenmann) (05/25/89)
Actually, what I'd really like to see is some structure to the lisp
directory. Right now, there's a huge amount of stuff all jumbled
together; novices have no idea what's available, and administrators
with limited disk space have problems figuring out what can be
trimmed (if, for example, your system doesn't support rmail and uses
mh-e instead). I'd propose an organization something like:
lisp/core - core elisp needed to run a basic Emacs; things like
files.el and simple.el would wind up here.
lisp/terms - already exists
lisp/modes - various modes available, named so people can easily
see what they're for.
lisp/interfaces - interfaces to various other systems (eg dbx.el,
mh-e.el and the various sublisp things). This might
have subdirectories for each interface package, eg
interfaces/mh. This is also a good place to put
window-system specific files (eg interfaces/x,
interfaces/suntools, etc).
lisp/packages - for things like saveconf.el that are a bundle of
functions, but not a mode.
lisp/functions - useful random functions; eg cl.el
lisp/misc - things that don't fit into any of the above categories
lisp/contrib - contributed elisp code that hasn't been really
looked at by the FSF. Code in here should normally
either be dropped or migrated into one of the above
directories depending on whether people use it or
not.
The only things left in lisp would then be a few odd files, such as
default.el, site-init.el, and so on (or perhaps these could get
demoted to lisp/local).
Also needed is some sort of a README giving a one or two-line
description of what each elisp file does for you. This would allow new
users to browse over it and find out interesting things to try out
(like saveconf.el, which I only found about by reading the
changes-in-Emacs file -- and I only read that because I'm the admin
here).
If people are interested in this, I'll volunteer to start putting
together a README and a suggested list of what elisp files get moved
to what directories.
--
"I shall clasp my hands together and bow to the corners of the world."
Number Ten Ox, "Bridge of Birds"
Chris Siebenmann ...!utgpu!{ncrcan,ontmoh!moore}!ziebmef!cks
cks@white.toronto.edu or ...!utgpu!{,csri!}ckscire@CISCO.COM (cire|eric) (05/29/89)
The proposed solution to the info overload also will require changes to various functions. The one that comes immediately to mind is load-lib. It would have to modified to decend probably one directory level when looking for things on the load-path. Of course this can be avoided by simply building in all of the directories into the default load-path when gnuemacs is built. thoughts? -c cire|eric Eric B. Decker Token Ring Development cisco Systems - engineering Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941