--- Begin Message ---
Subject: |
24.0.91; Setting generated-autoload-file as local variable not working correctly |
Date: |
Mon, 14 Nov 2011 23:12:16 +0100 |
Recipe:
* Create file 'testautoload.el' in /home/whatever/test containing
--------------------
;;;###autoload
(defun testautoload-testfunc ())
;; Local variables:
;; generated-autoload-file: "foo.el"
;; End:
--------------------
* Now create autoload file using (all in one line)
emacs --batch -l autoload -f toggle-debug-on-error
--eval '(setq generated-autoload-file "/home/whatever/test/foo.el")'
-f batch-update-autoloads /home/whatever/test
You'll see:
...
Wrote /home/whatever/test/foo.el
Making generated-autoload-file local to *autoload-file* while let-bound!
Generating autoloads for testautoload.el...
Generating autoloads for testautoload.el...done
Saving file /home/void/test/foo.el...
Wrote /home/void/test/foo.el
(No changes need to be saved)
and the file foo.el will be generated (BTW, shouldn't the above
*autoload-file* better denote the actual file name?)
* Now simply call the above command again. You'll get:
Debugger entered--Lisp error: (wrong-type-argument listp
"77d69bf537d61f438126776e130fef3d")
time-less-p("77d69bf537d61f438126776e130fef3d" (20161 36303))
update-directory-autoloads("/home/whatever/test")
apply(update-directory-autoloads "/home/whatever/test")
batch-update-autoloads()
[...]
This is due to the following autoload header in foo.el:
;;;### (autoloads (testautoload-testfunc) "testautoload" "testautoload.el"
;;;;;; "77d69bf537d61f438126776e130fef3d")
;;; Generated autoloads from testautoload.el
where the md5-looking hex-string is obviously not a time.
--- End Message ---
--- Begin Message ---
Subject: |
Re: bug#10049: 24.0.91; Setting generated-autoload-file as local variable not working correctly |
Date: |
Thu, 17 Nov 2011 09:36:20 +0100 |
User-agent: |
Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.91 (gnu/linux) |
Glenn Morris writes:
> The problem only occurs when the buffer-local value of
> generated-autoload-file points to the same file as the global value.
> This should be fixed, but in the meantime you can work around it by
> simply not setting the buffer-local value (because setting it to the
> global value is at best a no-op).
I can confirm it is fixed; thank you!
You're right of course that those variables are a no-op, but they come
from the CEDET Emacs-merge and I'd like to keep them to make merging
easier.
-David
--- End Message ---