When I invoke elint-current-buffer on a buffer of Lisp code, Emacs starts dragging in 75 !! compressed .el.gz files, leaving me with a huge pile of unwanted active buffers containing those files.

Is there any way to set a config option (or do something else) to avoid this issue? I searched for elint doc, but could only find an empty EmacsWiki page, nothing in the Emacs/Elisp manuals, no meaningful doc on the web.

1 Answer 1


This is somewhere between fully intentional and a bug. I'm not sure towards which side this one leans to, so I'll just let the sources speak for themselves:

(defun elint-add-required-env (env name file)
  "Augment ENV with the variables defined by feature NAME in FILE."
  (condition-case err
      (let* ((libname (if (stringp file)
            (symbol-name name)))

         ;; First try to find .el files, then the raw name
         (lib1 (locate-library (concat libname ".el") t))
         (lib (or lib1 (locate-library libname t))))
    ;; Clear the messages :-/
    ;; (Messes up the "Initializing elint..." message.)
;;; (message nil)
    (if lib
        (with-current-buffer (find-file-noselect lib)
          ;; FIXME this doesn't use a temp buffer, because it
          ;; stores the result in buffer-local variables so that
          ;; it can be reused.
          (setq env (elint-env-add-env env elint-buffer-env)))
          ;;; (with-temp-buffer
          ;;;   (insert-file-contents lib)
          ;;;   (with-syntax-table emacs-lisp-mode-syntax-table
          ;;;     (elint-update-env))
          ;;;   (setq env (elint-env-add-env env elint-buffer-env))))
          ;;(message "Elint processed (require '%s)" name))
      (error "%s.el not found in load-path" libname)))
     (message "Can't get variables from require'd library %s: %s"
              name (error-message-string err))))

The crucial part here is find-file-noselect. To recapitulate, elint is a package that lints elisp files by a set of built-in rules and rules that are created by scanning both the source buffer and all required libraries. The latter is done recursively to catch them all. Now, if it were using temporary buffers to do this, you wouldn't ever know of it, but it doesn't and instead goes for the horrifictried and true way of opening extra buffers, storing buffer-local data in them and keeping them around in case someone lints stuff again.

I'm afraid there's no option to customize this behavior. Hand in a bug or better, if you have an idea how to do better, a patch.

Personally, I wouldn't bother. Use M-x byte-compile-file and look at the compilation buffer instead. Its warnings cover everything elint does and unlike elint, the byte-compiler gets improved on a regular basis. The excellent flycheck package hides this manual step for you and integrates the warnings right where they belong, into the source buffer in form of squiggly lines.

  • Thanks for the good answer. I was thinking to myself, "I wonder if I should just learn how to use the byte compiler instead, and delete the .elc files if I don't want them. Better than having 75 unwanted buffers around." Now that I've just seen your answer and recommendation, I'll go that route, and forget about elint.
    – Kevin
    Jun 24, 2016 at 21:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.