Helmut Eller eller.helmut@gmail.com writes:
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.
Fair enough, but the problem still exists even if you move them to lib. It is solved relatively elegantly with this technique, which is what I just pushed.
(eval-and-compile (require 'cl-lib nil t) ;; For emacs 23, look for bundled version (require 'cl-lib "lib/cl-lib"))
In the end if you think this modularization is mostly about asthethics, I can agree. But I argue we should be slightly arty if that brings readability, more developers, and flexibility for current/unseen scenarios.
Anyway, I agree this debate is not really priority, I was just seeing what I could squeeze out of this.
I think the priority is fixing broken stuff and adding robustness. Then refactorings will become almost self-evident.
See the latest commit for the changes that address the latest latest concerns. Mainly two points;
* No more Emacs 23 gotchas.
* There is a new "traditional-recipe" test that complements the autoload case. It launches a separate emacs process with a very bare .emacs and launches slime there.
* I've now enabled the contrib tests in the Travis CI. I had to skip 2 tests, but we went from 184 to 297 tests, which is good, I think.
The contrib tests are tested in separate runs: we now have this in travis:
- LISP_BIN=sbcl EMACS_BIN=emacs make clean check - LISP_BIN=sbcl EMACS_BIN=emacs-snapshot make clean check - LISP_BIN=sbcl EMACS_BIN=emacs make clean check-fancy - LISP_BIN=sbcl EMACS_BIN=emacs-snapshot make clean check-fancy
Luís is working on a big improvement to this, stay tuned...
The testing code is probably the easiest to move.
OK, nice. What's second-easiest? :-)
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.
But at least the variable "slime-contribs" and "slime-setup" must be there, I think. Well as long we don't break any existing recipes.
"urge-recompile" doesn't sound obsolete as long as Emacs loads .elc files that are older than the corresponding .el file.
"make compile" checks mtimes. Would you be willing to use something like this in your ~/.emacs instead?
(defadvice slime (before slime-urge-bytecode-recompile activate) (let ((default-directory slime-path)) (unless (zerop (shell-command "make compile 2>&1 | tail -1 | grep '0 files compiled'")) (when (and (file-readable-p "slime.elc") (y-or-n-p "Reload slime.elc?")) (load "slime.elc")))))
Or moving that code to that slime-debugging contrib?
João