[slime] swank-loader could use ASDF (#65)

[João Távora]

[CCing slime-devel]

François-René Rideau <notifications at github.com> writes:

> On SBCL, (time (require :asdf)) takes .15s, but total SLIME startup
> time is about 3s, so ASDF doesn't seem to be the bottleneck.

I didn't say that it was, and yes that matches my times. I am mostly
curious as to the proportion of ABCL's 2 seconds to the total current
SLIME startup time.

> On most implementations, you don't need to compile asdf if you use the
> implementation's provided ASDF (assuming it's recent
> enough).
>
> Otherwise, yes, the first time around, you get to compile asdf — but
> hopefully, that's only the case on SCL.

It's also the case on most Allegros. Even 9.0 doesn't have the newest
ASDF, it seems to have 2.23.7. But a one-time wait per lisp
implementation is not so bad for me.

> Yes, it makes sense to me that each slime extension should get its own
> directory, its own .asd file, etc.

In case it wasn't clear, the mock tree I gave in the last email were the
contents of the ~/.emacs.d/elpa dir after installation.

So the slime source repo, the main .asd file can be still be the "all in
one" that you propose in pull request #80. Those small .asd files can
easily be auto-generated when packaging. Maybe this makes sense so as
not to disrupt the current repo organization too much.

In the el-get case, the installed software in ~/.emacs.d/el-get *is* the
source repo. So non-third-party contribs are loaded slightly
differently, while third-party contribs would be just like in the ELPA
case.

> There's a slight issue of how to communicate the search path between
> Emacs and ASDF, however: push things to the central-registry?

Is let-binding ASDF:*CENTRAL-REGISTRY* very bad? I sometimes do that and
it works ok. We could set it to the same path where we have the .el
file. This would have to be tested and as robust as possible of course.

> source-registry? Add an Emacs-specific sysdef search function?

I'm not familiar with any SOURCE-REGISTRY var. And also would avoid, if
possible, replicating in emacs-lisp what might already be in ASDF.

João