On Sun, Jan 12 2014, João Távora wrote:
Helmut Eller eller.helmut@gmail.com writes:
I'm not very enthusiastic about that. The technical reason to do it isn't so obvious. There may aesthetic reasons, but those are, as always, debatable.
OK. But I just gave you one such asthetic reason
me> The only thing that bugs me is the growing list of "bundled" third me> party files at top level. Helmut, can we move these to a new me> "vendor" dir?
and apparently won the debate immediately :-)
Having cl-lib and ert in the toplevel directory would be problematic because they conflict with the libraries in Emacs 24. That's a technical reason to move them out of the load-path.
Which files are you more/less enthusiastic about moving around?
The testing code is probably the easiest to move.
[...]
I don't think these commands need to be documented in the manual, but they are useful for debugging.
Perhaps they should be in a "slime-debugging" contrib and not in SLIME? Or in slime-tests? At the least they should be reprefixed "slime--".
Actually, it might be good to move everything related to contribs to a contrib. So that SLIME, including slime-autoloads, doesn't need to know that contribs exist.
Actually a lot of code seems like it would make a good candidate for that contrib/file. For example the curious "urge-recompile" and the manual recompilation of some functions, which I think were made obsolete by "make compile" are more candidates.
"urge-recompile" doesn't sound obsolete as long as Emacs loads .elc files that are older than the corresponding .el file.
Helmut