M-x slime [No match] about slime

[pedro-w]

You probably have figured this out yourself, but anyway, I think that version 2.29.1 of SLIME is obsolete - better to get the one from MELPA (20240125 is the latest, I think.) In your second .emacs file, you are enabling the MELPA repository, which you weren't in your first one.
With the 2.29.1 version I get the same problem as you; SLIME isn't actually activated even though the files seem to be installed.

[pedro-w]

I haven't tried either (beyond looking at its contents) but I believe it would be usable - the one that isn't is nongnu ELPA (linked here) because they have removed slime-autoloads.el. During installation it is replaced with an autogenerated one which doesn't work, because slime doesn't use the magic comments (;;;###autoload) which would allow emacs to detect which functions should be made into autoloaders.

In other words, normally the function slime would be registered by code in slime-autoloads.el and typing M-x slime would cause the rest of the package to be loaded. However the 'broken' slime-autoloads.el doesn't register anything, so emacs doesn't know anything about function slime, hence M-x slime gives the "[no match]" error.

If you install the ELPA package and cat ~/.emacs.d/elpa/slime-2.29.1/slime-autoloads.el you'll see it's different from the one in this repo.

I think that's correct - let me check it before we get any further though!

[phikal]

At the moment, MELPA works and ELPA doesn't because they're modifying the github release tarball. (If I'm wrong about that, please someone correct me)

Note that NonGNU ELPA doesn't modify any tarball, we use the last commit that bumps the version tag and use that as the basis to prepare a .tar package that is hosted by the archive. As part of that process, the ELPA build server generates an -autoloads.el and -pkg.el file, which in this case get overwritten.

[pedro-w]

(require 'slime) in your ~/.emacs will work, I have no doubt.

The downside is that it will load slime as soon as emacs starts, whether you need it or not. What should happen is that emacs package manager loads slime-autoloads.el, which contains (effectively) a lightweight 'stub' of the slime function. All this does when called is to load the actual slime package, overwriting itself. Emacs will load quicker and with less memory usage because defers loading the actual package (which contains many functions) until the first time it's used, thereafter it will be just as if you'd require'd slime. This may not be a big deal to you; it can become significant if you've installed lots of packages - loading them all at startup would be slow.

The problem here was that the slime-autoloads.el was wrong - it didn't even load the slime stub hence when you typed M-x slime it didn't know anything about the slime function.

It should be fixed in ELPA after the next release, see #809
Does that make sense?

[stassats]

2.29.1 is the latest version of Slime. I have never used melpa, but I've seen a lot of confusion from those who use it.

[pedro-w]

@stassats thanks for the information. When I install SLIME (with MELPA enabled) I have a choice of

 20240125.1336 (melpa), 2.29.1 (nongnu).

The nongnu version has a date of 2024-Jan-24 (reference)
and the MELPA version also claims to be 2.29.1
so they ought to be very similar, however it's still true that the MELPA one works for me but the nongnu one gives the [no match] error as reported by @7stud.
I can't see anything in messages to indicate why the nongnu one is not loaded.

[stassats]

The elpa/melpa/whatever packages are maintained by someone (something) else. So I have no idea what they do.

[pedro-w]

I have never used melpa, but I've seen a lot of confusion from those who use it.

Understood, but literally item 1 in your quick setup instructions is "Set up the MELPA repository"

As far as I can see, the nongnu ELPA version seems to have inexplicably omitted your slime-autoloads.el from their tarball and it gets replaced with an autogenerated version that doesn't work.

I see there was some sort of beef with ELPA recorded here

 ;; FIXME: Upstream has accidentally diverged, see
 ;; https://github.com/slime/slime/pull/648
 (slime			:url "https://github.com/slime/slime"
  ;; According to `git log -- NEWS`, seems to be the closest to "maintainer".
  :maintainer "Stas Boukarev <[email protected]>"
  ;; FIXME: Apparently upstream is not cooperative enough :-(
  ;; https://github.com/slime/slime/pull/648
  :merge t
  :doc "doc/slime.texi")

and in the linked PR #648

Do you want me to try and contact that someone or something at ELPA because it would be good to have this working "out of the box"? I'm happy to give it a go!

[stassats]

Part of the reason I don't understand or trust ELPA, why did they include code from some third party branch? And then can't remove it. I don't really want to be fixing their mistakes.

[7stud]

You probably have figured this out yourself,

No. I just got lucky when I decided to try the .emacs file from emacs4cl. I could see some differences in ~.emacs.d/, but I didn't know the significance of them.

Here was the directory for the 29.2 ~/.emacs.d when I couldn't get slime to work:

~/.emacs.d% ls
auto-save-list eln-cache      elpa
~/.emacs.d% cd elpa
~/.emacs.d/elpa% ls
archives               macrostep-0.9.2.signed slime-2.29.1
gnupg                  paredit-26             slime-2.29.1.signed
macrostep-0.9.2        paredit-26.signed

Here is the directory for the 29.1 ~/.emacs.d when I got slime to work:

~/.emacs.d% ls
auto-save-list custom.el      eln-cache      elpa
~/.emacs.d% cd elpa
~/.emacs.d/elpa  ls
archives                         paredit-20221127.1452
gnupg                            rainbow-delimiters-20210515.1254
macrostep-20230813.2123          slime-20240125.1336

Here's custom.el:

(custom-set-variables
 ;; custom-set-variables was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(package-selected-packages '(rainbow-delimiters paredit slime)))
(custom-set-faces
 ;; custom-set-faces was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 )

That's identical (except for the package names) to what was in my first .emacs file, and I assume custom.el gets read somehow just like .emacs. Okay, that's setup here:

;; Write customizations to a separate file instead of this file.
(setq custom-file (expand-file-name "custom.el" user-emacs-directory))
(load custom-file t)

I'm not sure what the point is of having both a .emacs file and a custom.el file.

So, the main differences I see between the two emacs installs are package names like:

slime-2.29.1
slime-2.29.1.signed

v.

slime-20240125.1336

[7stud]

Part of the reason I don't understand or trust ELPA, why did they include code from some third party branch? And then can't remove it. I don't really want to be fixing their mistakes.

@stassats

For a new emacs user, what is your recommended method for installing packages, and specifically slime?

[pedro-w]

I'm coming to the conclusion that this isn't the right place to complain; both MELPA and nongnu ELPA take the outputs of this project and package them in their own ways. MELPA updates theirs every time there's a new commit and ELPA take the github releases. At the moment, MELPA works and ELPA doesn't because they're modifying the github release tarball. (If I'm wrong about that, please someone correct me)

So, if you want to get going today, use MELPA. In the meantime I will try and contact whoever is behind the ELPA and see if I can figure out why the difference and if it can be brought into sync, because I'd like slime to be working without this hassle!

For reference, my .emacs looks like

(custom-set-variables
 ;; custom-set-variables was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(inferior-lisp-program "ecl" t)
 '(inhibit-startup-screen t)
 '(package-selected-packages '(slime paredit tj3-mode)))
(custom-set-faces
 ;; custom-set-faces was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 )

(require 'package)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t)
(setq inferior-lisp-program "ecl")
(package-initialize)

[stassats]

Is the "Source code(tar.gz)" from the release page really unusable? I, naturally, haven't tried using it.

[stassats]

A pull request with magic would be welcome.

[pedro-w]

I've asked a question on the emacs mailing list (hopefully the right place) as I need a bit of guidance on fixing this

[luismbo]

@phikal slime-autoloads.el was removed from emacs/nongnu.git in this commit: https://git.savannah.gnu.org/gitweb/?p=emacs/nongnu.git;a=commit;h=6e0d67b9b7ae0fc31902609ab7525826b292c384

[phikal]

I know, that is because they don't have to be tracked in the repository.

[7stud]

@pedro-w

So, if you want to get going today, use MELPA.

On stackoverflow, Ehvince asked me to try adding (require 'slime) to my .emacs file, and that got rid of the M-x slime [No match] problem. In a buffer containing a lisp program, I did M-x slime, then another window opened with the slime REPL. Both C-c C-c with the cursor inside a function, and C-x C-e with the cursor just after the closing paren of a function succeeded in compiling the function in the slime REPL, then I could switch to the slime REPL and execute the functions:

Can you confirm if that works for you?

~/.emacs:

(custom-set-variables
 ;; custom-set-variables was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(package-selected-packages '(slime)))
(custom-set-faces
 ;; custom-set-faces was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 )

(setq inferior-lisp-program "sbcl")
(require 'slime) 

~/.emacs.d:

~/.emacs.d% ls
auto-save-list eln-cache      elpa

~/.emacs.d% cd elpa 

~/.emacs.d/elpa% ls
archives               macrostep-0.9.2        slime-2.29.1
gnupg                  macrostep-0.9.2.signed slime-2.29.1.signed