11

For the warning of

Package cl is deprecated

is there any easy fix for it?

Here is a piece of code I copied from somewhere (that I don't know how to fix):

(eval-when-compile (require 'cl))
(defun sanityinc/add-subdirs-to-load-path (parent-dir)
  "Adds every non-hidden subdir of PARENT-DIR to `load-path'."
  (let* ((default-directory parent-dir))
    (progn
      (setq load-path
            (append
             (remove-if-not
              (lambda (dir) (file-directory-p dir))
              (directory-files (expand-file-name parent-dir) t "^[^\\.]"))
             load-path)))))
Drew
  • 77,472
  • 10
  • 114
  • 243
xpt
  • 467
  • 1
  • 4
  • 17
  • 1
    There is no error, and no error message. The message is a warning - just an FYI/heads-up. cl.el is deprecated but not desupported. Deprecated does not mean desupported. You're encouraged to use its suggested replacement, but cl.el still works just fine. – Drew Jul 20 '21 at 15:58
  • 4
    No, it does not work "just fine" for me, I wouldn't bother looking into it otherwise. That warning message is eclipsing the LSP mode import project prompt, causing all my projects to be in blacklisted directory. Took me quite a while to figure out why as the LSP mode was quite new and overwhelming to me. – xpt Jul 21 '21 at 13:04
  • 1
    I see. So the problem is other code that you're using, which itself stopped working with just cl.el loaded. There's nothing wrong, in itself, with using cl.el. But apparently your version of Purcell's code is out of date - see @manuel's answer. This is part of the fallout of people changing to use cl-lib.el: dependencies need to be updated/fixed. – Drew Jul 21 '21 at 15:31
  • For sure. thanks @Drew. – xpt Jul 21 '21 at 15:34
  • The easy way out is to use cl-lib instead of cl. A more robust route is to stop using the package all together -- it is a package with the clear purpose of porting Common Lisp packages to Emacs. There are several constructs in it which is plain wrong from an Emacs Lisp point of view, but apparently they are designed that way since "that is how Common Lisp" do it. The drawback of the cl-lib debacle is that useful functions like union no longer is available in normal elisp. – Lindydancer Mar 08 '23 at 05:53

3 Answers3

4

It looks like the code comes from Steve Purcell's emacs.d.

He actually updated it to use cl-lib now, so you can try his more recent version:

(defun sanityinc/add-subdirs-to-load-path (parent-dir)
  "Add every non-hidden subdir of PARENT-DIR to `load-path'."
  (let ((default-directory parent-dir))
    (setq load-path
          (append
           (cl-remove-if-not
            #'file-directory-p
            (directory-files (expand-file-name parent-dir) t "^[^\\.]"))
           load-path))))
Manuel Uberti
  • 3,250
  • 19
  • 37
  • 1
    Don’t tell him that; he won’t learn as much. – db48x Jul 20 '21 at 06:10
  • 2
    You are right, but maybe it is still worth pointing him to the original code he copied just to look at the changes. – Manuel Uberti Jul 20 '21 at 07:06
  • OMG, I was just shooting into the dark, and didn't expect anyone can answer it. And you've hit the nail precisely! THX! – xpt Jul 20 '21 at 13:17
  • "Don’t tell him that; he won’t learn as much" I wish that db48x will need to maintain PL/I code once a year, then he might, just might, have some empathy. – xpt Jul 20 '21 at 13:20
  • 1
    In defense of @db48x, he provided an answer (and it is a good answer) to help you. Part of the problem is copying code without understanding what it does. And, yes, copying the updated code fixes the problem, but understanding the code that you are copying enough so that you can debug it when (not if) problems arise is important: "give a man a fish ..." and all that... – NickD Jul 20 '21 at 15:22
  • I’ve done a lot of software archaeology in my day, and I know well the temptation to blindly copy some code to get things working. That lack of understanding will always come back to bite us eventually. I could go on at length, but thinking about it gives me flashbacks of my work with autoconf/automake. – db48x Jul 20 '21 at 21:50
  • Sigh, putting someone into a fire every five years won't make him a good firefighter. You need to ask yourself, does he even have the basic knowledge and skills to fight the fire before putting him into the fire. Throwing a baby into a river will not force him to learn swimming fast either. It will only drown the baby. There are always things we don't know, and not everybody want to be a car mechanic when all he want is just to drive his car. Have some sympathy, please. – xpt Jul 21 '21 at 13:16
  • Anyone that uses Linux, have you ever heard Linux kernel people complaining that the average John is not understanding/helping/contributing in kernel development? Why some elisp people think he has the right to lecture the world? I guess most people comes here to get helps, not to get ashamed. – xpt Jul 21 '21 at 13:48
  • 4
    There was no attempt to shame AFAICS (after all, it was a comment on an answer, not on the question): maybe he should have added a smilie, but I took it as a tongue-in-cheek remark. And yes, you might just want an answer to the question and move on with your life, but these postings are used by people long after the initial question/answer session: it is useful to have answers explaining the why, not only the how. In fact, the why answers stand the test of time much better. My advice is: assume positive intent - I think you'll be much happier in the long run :-) – NickD Jul 21 '21 at 17:14
  • 1
    yeah, true. thanks. – xpt Jul 22 '21 at 15:14
3

Just remove the first line, which loads the cl package, and then fix any errors that result.

In particular, functions like remove-if-not are now called cl-remove-if-not, and are always available (technically they are autoloaded). The cl package just adds an alias for it called remove-if-not to allow older code to still work.

db48x
  • 17,977
  • 1
  • 22
  • 28
  • On the off-chance we have to use old versions of emacs, too, is there an idiom we should use? Something like (if (< emacs-major-version XXX) (remove-if-not ...) (cl-remove-if-not ...)). That's pretty cumbersome actually: I guess we should live with the deprecation warning for a while yet. Looks like XXX = 28. – Robert P. Goldman Nov 02 '23 at 14:23
0

I think my reason for getting this error was I was loading complete

(load "complete")

After removing this, the warning went away.

PatS
  • 155
  • 6