Add recipes/sly-quicklisp

[joaotavora]

Another third-party SLY extension

[purcell]

Thanks. The autoload here doesn't actually do what it says, right? It will result in the extension being added to sly-contrib at Emacs start-up time, possibly even before that variable's default value has been set by the loading of sly.

[joaotavora]

Right. The idea, as in sly-macrostep, sly-names-readtables and sly-hello-world, is that that variable's definition and default value is in SLY autoloads file, sly-autoloads.el, which I believe is always loaded before sly-somecontrib-autoloads.el. Hence there should be no problem.

At least I think so theoretically. In practice, I've tested a vanilla Emacs -Q scenario, with and without the SLY package loaded, in various combinations, and came across no problems. But I might be missing something or depending on some package.el implementation detail that is not guaranteed to survive.

What specifically is your objection to this approach, and what do you suggest I do to have package-installing a SLY contrib lead to that contrib automatically activating itself in the next M-x sly invocation?

[purcell]

That's probably safe, then, and I'm not going to push the following point, but I want to take this chance to point out that you should never assume that when a user has a package installed, they always want to use it.

The Emacs standard library provides many packages which are available, but which do not aggressively auto-enable themselves, and third-party packages are supposed to work the same way. So to that end, I'd strongly suggest directing users to alter sly-contribs themselves, or at least to not ;;;###autoload those changes.

[joaotavora]

point out that you should never assume that when a user has a package installed, they always want to use it.

I am aware of this, but I never really grokked it besides a philosophical standpoint. And I also do not understand why many many packages, notably major-mode packages, are exempt from this commandment... Here's markdown-mode.el assuming a lot of stuff about what happens when I open certain files, jus by installing it.

;;;###autoload(add-to-list 'auto-mode-alist '("\\.markdown\\'" . markdown-mode))
;;;###autoload(add-to-list 'auto-mode-alist '("\\.md\\'" . markdown-mode))
;;;###autoload(add-to-list 'auto-mode-alist '("\\.text\\'" . markdown-mode))

And it's hardly a misbehaving package, I believe all major-mode packages to do the same. Why shouldn't a specific extension to a specific package of the emacs ecosystem be allowed a similar approach?

and I'm not going to push the following point,

I understand, but I'm interest in your opinion nonetheless.

[purcell]

It's a grey area, so my interest here is in laying out the guidelines as I've come to understand them. I can understand your viewpoint w.r.t. providing an extension to sly. An analogous example in the Emacs standard library is something like erc-autoaway, which is an erc extension: it doesn't auto-enable itself. Packages should behave the same whether or not they are bundled in the standard library.

In general, major modes are apparently the one exception to this rule, so long as the filename patterns are definitive: if you installed two major modes for Python, you'd expect to have to configure which one should take precedence, so it's okay for both of them to auto-enable. I've submitted a PR to remove .text from the markdown-mode autoloads above, because that's inappropriate.

YMMV :-)

[joaotavora]

you'd expect to have to configure which one should take precedence, so it's okay for both of them to auto-enable.

The same applies to SLY extensions, then: you can always configure them by hand after package initializations.

I've submitted a PR to remove .text from the markdown-mode autoloads above, because that's inappropriate. YMMV :-)

In all honesty, I hope the author doesn't take your PR :-). You see, I like my mileage to vary as little as possible, and having .text files directed to something that I've installed recently doesn't sound that dumb. Or, to put it another way, if a package that I've trusted enough to install intrudes on something I haven't thought of configuring, that's OK.

Then again, sometimes a package I've installed does screw up, and I slightly regret my benevolence.