slime on github

[Helmut Eller]

On Sun, Jan 12 2014, João Távora wrote:

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