slime on github

[João Távora]

Helmut Eller <eller.helmut at 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