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