4

I installed emacs via brew: brew install emacs and got version 28.1 (my OS version is macOS 11.6.1). I immediately ran package-install + slime.

When I run slime command I get:

Package cl is deprecated

When I run the command for 2nd time I get:

Wrong number of arguments (3 . 4), 2

I am complete newbie to emacs and lisp, I'm just trying to set up the environment so I can complete tutorial.

When running with toggle-debug-on-error option I get the following output:

Debugger entered--Lisp error: (wrong-number-of-arguments (3 . 4) 2)
  #f(compiled-function (obsolete-name current-name when &optional docstring) "Make OBSOLETE-NAME a variable alias f$
  (define-obsolete-variable-alias 'common-lisp-glossary-fun 'common-lisp-hyperspec-glossary-function)
  eval-buffer(#<buffer  *load*-964107> nil "/Users/user/.emacs.d/elpa/slime-2.26.1/li..." nil t)  ; Readin$
  load-with-code-conversion("/Users/user/.emacs.d/elpa/slime-2.26.1/li..." "/Users/user/.emacs.d/$
  require(hyperspec "lib/hyperspec")
  eval-buffer(#<buffer  *load*> nil "/Users/user/.emacs.d/elpa/slime-2.26.1/sl..." nil t)  ; Reading at bu$
  load-with-code-conversion("/Users/user/.emacs.d/elpa/slime-2.26.1/sl..." "/Users/user/.emacs.d/$
  autoload-do-load((autoload "slime" "Start a Lisp subprocess and connect to its Swank s..." t nil) slime)
  command-execute(slime record)
  execute-extended-command(nil "slime" "slime")
  funcall-interactively(execute-extended-command nil "slime" "slime")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)
user3056783
  • 141
  • 3
  • 1
    "Package cl is deprecated" doesn't mean `cl` doesn't work (it is still present, and it works just fine). It's just a suggestion (to the authors of the code in question) to switch to `cl-lib`. – phils Apr 27 '22 at 11:32
  • 2
    `M-x toggle-debug-on-error` and paste the backtrace from the error into your question. – phils Apr 27 '22 at 11:34
  • 1
    @phils thanks for suggestion, I updated my question with the output – user3056783 Apr 27 '22 at 14:09
  • 1
    This is apparently a duplicate of the problem raised in question https://emacs.stackexchange.com/q/71503/105. (Can't close as dup because that one doesn't have an upvoted answer.) – Drew Apr 27 '22 at 15:07

1 Answers1

0

It looks like define-obsolete-variable-alias is defined as an Emacs Lisp macro.

I would like to guess that there might be something in how the macro expansion for define-obsolete-variable-alias is being compiled, such that may be resulting in the error.

If it may be possible to develop a short sort of workaround for the error, the following should serve to ensure that hyperspec.el is newly recompiled by Emacs. This uses a syntax like for keys/commands entered in the Emacs minibufer

  1. M-X find-library RET slime RET
  2. M-X find-file RET lib/hyperspec.el RET
  3. M-X byte-compile-file RET RET

Concerning the two 'RET' i.e 'return' keys entered with the third item: When not specifying any file in the interactive call to byte-compile-file, or when entering an empty string when it asks for a file in the minibuffer, then it should use the file in the selected buffer - e.g hyperspec.el under that source location.

This basically recompiles the "lib/hyperspec.el" located under the same load-path directory as "slime.el". This recompiled hyperspec.elc would then be loaded when the following is evaluated newly, in slime.el

(require 'hyperspec "lib/hyperspec")

One of slime.elc (byte-compiled file) or slime.el (the source file for slime.elc) would have been loaded as due to an autoload form created when the slime package was installed, such that the slime interactive command would load slime (dot-elc or dot-el) to define the actual slime command. Emacs then tries to load every library that has a require form in slime.el, when evaluating the bytecode (or source code) for slime.el, thus to the point where the macroexpansion (??) fails.

After recompiling hyperspec.el, hopefully it might serve to clear up any possible issue with the compiled macroexpansion form, at this instance.

I don't believe it should be necessary to restart Emacs, at that point. Entering the interactive slime command in the minibuffer again then, does the issue clear up somehow?

If that does not work out, then if simply loading that hyperspec.el as a source file -- as instead of its (ordinarily preferred) hyperspec.elc -- this might serve to work around the issue, albeit, skipping any optimizations in any byte-compiled form of the file. Removing hyperspec.elc would be one way to approach this, as to ensure that hyperspec.el is loaded instead.

Sean Champ
  • 60
  • 5
  • Thanks for the instructions. I followed them but got: ``` Compiling file /Users/username/.emacs.d/elpa/slime-2.26.1/lib/hyperspec.el at Thu Apr 28 19:41:41 2022 hyperspec.el:1318:1: Error: Wrong number of arguments: (3 . 4), 2 ``` – user3056783 Apr 28 '22 at 17:45
  • I did not have `hyperspec.els` in `~/.emacs.d/slime-2.26.1/lib` but `hyperspec.el~` so not sure what the tilde is about. I removed that file but I'm still getting package cl is deprecated error. – user3056783 Apr 29 '22 at 06:04
  • You will keep getting tyhe depreciation error until slime is rewritten but it is not an error and everything will work proerly for cl. It is a warning that a future emacs will remove cl but that has not happened yet. – mmmmmm Sep 26 '22 at 06:49
  • 1
    Thanks for the heads up, I had the same problem. I finished fixing the problem. In hyperspec.el I altered the line: (define-obsolete-variable-alias 'common-lisp-glossary-fun 'common-lisp-hyperspec-glossary-function "unknown") by adding that last string "unknown". It is supposed to represent when something becomes obsolete. I could then byte-compile-file just fine, and slime now loads. – Drew Mills Dec 02 '22 at 21:17
  • @DrewMills Thanks its works, but what happened? What it's trade off and what I must watch for, if something break. – SinaMobasheri Aug 16 '23 at 21:05