Helmut Eller heller@common-lisp.net writes:
Hence I moved from the idea of a contrib/ directory to the idea of a modules/ directory where even core features can be placed.
That's exactly what I'd like to avoid. I don't want to have more core features to support. The reorganization thing sounds like an excuse for introducting more features.
It is, partially. I want a way to introduce new features that are clearly cut apart from the core.
What do you understand under "features to support"? And what do you understand under "support" in this context?
(Do you mean accomodating code from features you do not care about while hacking on some other code?)
Keeping the current organization increases the pressure to actually simplify the existing code instead of just moving bad code to other files.
I can understand that point. But it does not seem hold. New features seem to be piled up (and want to be piled up), but without much care about the rest of the code base, because -- in my eyes -- no one is able to keep an overview over the code base anymore.
And the weight of the existing code base seems to prevent any large-scale simplification. I for one try to keep my nose out of slime.el.
My intention is to remedy exactly this by an incremental approach.
-T.