'Symbol's value as variable is void' in callback from url-retrieve

Question

When executing the following I get an error:

(defun caller (func)
  (url-retrieve "http://m0smith.freeshell.org/"
   (lambda (status) (funcall func))))


(caller (lambda() (message "called")))

Result:

error in process filter: Symbol's value as variable is void: func

What is the best way to solve this problem? Basically I need to accept a callback from somewhere else, wrap it in another lambda and use that as the callback to url-retrieve.

If I change caller to

(defun caller (func)
  (url-retrieve "http://m0smith.freeshell.org/"
   `(lambda (status) (funcall ,func))))

it works. However, I cannot do this as func is being passed by flycheck and the macro expansion breaks it. To see the full context of what I am doing: https://gist.github.com/m0smith/b5961fda6afd71e82983

Answer 1

You can achieve this locally by using cl.el's lexical-let:

(eval-when-compile '(require 'cl))

(defun my-test-caller (func)
  (lexical-let ((ext-func func))
    (url-retrieve "http://www.google.com"
                  (lambda (status) (funcall ext-func)))))

(my-test-caller #'(lambda() (message "called")))

To be explicit as the help says:

Like `let', but lexically scoped.
The main visible difference is that lambdas inside BODY will create
lexical closures as in Common Lisp.

Now you can get the same effect by enabling lexical-binding which was added in Emacs 24.1. This is a buffer local variable that can be set and will enable lexical closures on all code in the buffer. So your buffer would look like this:

;; -*- lexical-binding: t; -*-

(defun my-lexical-test-caller (func)
  (url-retrieve "http://www.google.com"
                (lambda (status) (funcall func))))

(my-lexical-test-caller
 #'(lambda()
     (message "called from lexical-binding def")))

Answer 2

Enable lexical-binding for your library, with M-x add-file-local-variable-prop-line RET lexical-binding RET t.

Please do not use lexical-let as suggested by the other answer. Flycheck itself is not compatible with Emacs 23, so there is no point in trying to maintain Emacs 23 compatibility in your own code.