[sending this posting is against my better judgement :)]
* "Tobias C. Rittweiler" 87ps1u2qvj.fsf@freebits.de :
| I'd like to suggest a reorganization of the Slime sources. Some | not-so-long time ago, there has been some vague consensus of factoring | some parts of Slime out into a contrib/ directory. The intention of this | mail is to straighten out the vagueness while building upon the | consensus. | | a) to introduce a new file `swank-utils.lisp' (and perhaps also | `slime-utils.el') and collect common utility functions there in. | | Gripe: `swank.lisp' is currently almost 6000 lines long. As a | result, it's very hard to get an overview of what's there already, | and consequently what could be reused in other (or new!) parts.
slime.el is over 11k lines long. I think byte compiling slime.el in a new emacs and fixing all statically detected errors would be a start.
Splitting up slime.el into bunch of files along lines of functionality would give insights into how the common lisp code would need to be split up.
Unless you want to do this as a CVS branch, it may be better to plan for reorganization than decide directory structure upfront. i.e. do the splitting up in iterations and reorg bits at a time,
Personally I'd prefer the reorg done on a git repo outside of official CVS and synched back (on a branch perhaps)
| Also there's some stuff that can be very useful for foreign projects | that perhaps would like to take advantage, but don't want all of | SWANK (the arglist stuff comes to mind.) | | | b) to introduce a new directory `modules/' that contain self-contained | subsystems. For instance: | | modules/ | inspector/ | | fuzzy-compl/ | | These subdirectories contain both Common Lisp and Elisp code. It's | subject to further discussion what's the best way of loading these | subsystems. Are there special requirements?
My personal taste would be (at least initially) to put common lisp and emacs lisp in different directories:
emacs-lisp/slime-{inspector,fuzzy-completions}.el lisp/{inspector,fuzzy-completions}.lisp
And keep exactly one file per functional unit.
As an initial-cut the [backend]/swank-{cmucl,lw,...}.lisp would cut across these functional boundaries and have all the code for that lisp platform.
Rationale: You'd want to add one directory to load-path. There is no equivalent to load-path in cl but the same aesthetic applies: swank.lisp would look in one directory for "plugin" files -- viz lisp/ which has the lisp/{inspector,fuzzy-completions,...}.lisp files.
| The purpose is to reduce the line count of `swank.lisp' while | aiding understanding by explicitely decoupling of independent | subsystems. Also to establish the ground work for a plugin | architecture if this deems useful. | | | c) to introduce a new directory `backends/' and place all the | `swank-sbcl.lisp', `swank-clisp.lisp' &c files there. This is | merely for aesthetical reasons (less clutter in the main source | directory) and hence rather optionally.
-- Regards Madhu