Helmut Eller heller@common-lisp.net writes:
I propose:
a) to introduce a new file `swank-utils.lisp' (and perhaps also `slime-utils.el') and collect common utility functions there in. [...]
No consensus here. The basic structure, a few big files, should stay as it is.
What's the benefit?
b) to introduce a new directory `modules/' that contain self-contained subsystems. [...]
One requirement is that Slime, in the default configuration, should also work without the modules directory.
...
The purpose is to remove (bloated) features from Slime. Putting bloated code in it's own directory is a diplomatic way to remove a feature. The code in the modules directory is maintained (or not) by those people who care about it; not necessarily the Slime maintainers. Conceptually, the stuff in the module directory isn't part of Slime.
I deliberately widened that view to also include core features -- especially the inspector which you once classified as a such.
The reason is simple: The INSPECT-FOR-EMACS stuff spans almost 1000 lines and is mostly uninteresting, not-really-pretty looking code. However, one has to remark at this point that both these properties are somewhat inherent to the purpose of the code, as it describes layout and presentation. It's necessary cruft so to speak.
I'd really like to see this stuff swapped out into another file.
[...] Overall, I think Slime's file organization as it is now is quite ok. The problem is that some features take way to much code. Reorganizing files alone doesn't reduce the amount of code.
While reorganizing files alone doesn't reduce the amount of code per se, it _does_ reduce the amount of conceptually coherent code that I have to keep into my head at once. Or rather it helps in ignoring the bits that are uninteresting to the current problem.
(Of course, there's buffer folding. But I don't think that it works that well with `M-.' --- and it doesn't allow to leverage Common Lisp's package system, assuming multiple package definitions within one source file is a big no-no.)
-T.