slime on github

[João Távora]

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 :-) Which files are you
more/less enthusiastic about moving around?

>>> If you're breaking everybody's .emacs then you can just as well drop
>>> the non-autoload receipe.
>> I don't understand. AFAICT, the non-autoload recipe was not broken, and
>> I see no no reason to break it. In any case I'm _trying_ to do just the
>> opposite: not break user's ~/.emacs files.
> Well, you said that changes to the non-autoload recipe may be
> necessary. If you do that then you could also drop it entirely.

You misunderstood me when I said "complicate the non-autoload
installation recipe". I meant we must complicate our program to do
something akin to replacing:

    (require 'hyperspec ...)

with

    (require 'hyperspec "lib/hyperspec.el")

And that's quite different from "breaking everybody's .emacs",
ie. breaking existing instances of that recipe.

Again, that is something I don't want to do.

>> * We can deprecate slime-enable-contrib and slime-disable-contrib. I had
> Not sure what slime-enable-contrib promises.

Precisely my point.

> It would also be possible to enable resp. disable modes with these

I don't understand "reps. disable modes", but I agree they aren't very
useful. See the end of the mssage for a proposal.

> 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 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.

>> So, in the future, (mapc #'require slime-contribs) might be all that is
> Doesn't sound very idiomatic to me.  IMO, loading a package and enabling
> it should be separate steps.  The elisp manual seems to agree with me
> (elisp)Coding Conventions::

I think you may be misunderstanding the spirit of the guideline. The key
is

>    ...should not change Emacs's editing behaviour
                                  ^^^^^^^
It means you shouldn't change stuff like global keybindings or the value
of the `fill-column' variable, which makes perfect sense to me.

For example, just by `requiring' python-mode or ruby-mode, files with
those extensions will automatically be opened in that mode. Requiring
slime-autoloads does the same for lisp files and requiring some contrib
files could follow in the same spirit.

But to be clear, I *agree with you*, and my suggestion sucks, or at
least was very lacking. Contribs should rather be minor-modes defined by
`define-globalized-minor-mode'

So for most of them:

   (require 'slime-foo-autoloads)
   (slime-foo-mode 1) ;; prints a warning if there are more connections
                      ;; besides the current one

slime-repl's mode should be called something like slime-auto-repl-mode,
meaning a repl is automatically launched.

But these are suggestions for the future. There are most interesting
problems right now.

João