Remove quoting of lambdas in me-async-map.

[tychobrailleur]

When trying to execute the me-async-map, the function fails with a void-function error for closure:

Debugger entered--Lisp error: (void-function closure)
  signal(void-function (closure))
  (if (and (listp result) (eq 'async-signal (nth 0 result))) (signal (car (nth 1 result)) (cdr (nth 1 result))) (funcall func result))
  (unwind-protect (if (and (listp result) (eq 'async-signal (nth 0 result))) (signal (car (nth 1 result)) (cdr (nth 1 result))) (funcall func result)) (if async-debug nil (kill-buffer buf)))
  (if (null func) (progn (set (make-local-variable 'async-callback-value) result) (set (make-local-variable 'async-callback-value-set) t)) (unwind-protect (if (and (listp result) (eq 'async-signal (nth 0 result))) (signal (car (nth 1 result)) (cdr (nth 1 result))) (funcall func result)) (if async-debug nil (kill-buffer buf))))
  async-handle-result(identity (async-signal (void-function closure)) #<buffer *emacs*>)
  #f(compiled-function (it) #<bytecode -0x1cdee22885dc94b8>)(#<process emacs>)
  mapcar(#f(compiled-function (it) #<bytecode -0x1cdee22885dc94b8>) (#<process emacs> #<process emacs<1>> #<process emacs<2>>))
  me-async-map--finish((#<process emacs> #<process emacs<1>> #<process emacs<2>>) (closure (t) (_) (message "%s" (directory-files "/tmp"))) (lambda nil (>= (time-to-seconds (time-since '(26117 15670 906092 623000))) (or nil 300))) 1)
  apply(me-async-map--finish ((#<process emacs> #<process emacs<1>> #<process emacs<2>>) (closure (t) (_) (message "%s" (directory-files "/tmp"))) (lambda nil (>= (time-to-seconds (time-since '(26117 15670 906092 623000))) (or nil 300))) 1))
  timer-event-handler([t 26117 15671 954801 nil me-async-map--finish ((#<process emacs> #<process emacs<1>> #<process emacs<2>>) (closure (t) (_) (message "%s" (directory-files "/tmp"))) (lambda nil (>= (time-to-seconds (time-since '...)) (or nil 300))) 1) nil 935000 nil])

It seems however that quoting here is unnecessary – unless I am missing something?

[ag91]

Thanks @tychobrailleur , you found an issue indeed. Not sure why I quoted that lambda some time ago, must have been an experiment with the load-path. Anyway thanks for the fix!