Package: Emacs
Version: 29.0.50
The new handling of autoloads seems to have an unintended side effect:
When I install for example the `rudel` package from GNU ELPA, the
`rudel-autoloads.el` file created in
~/.emacs.d/elpa/rudel-0.3.2/rudel-autoloads.el
includes things like:
;;; Generated autoloads from rudel-backend.el
(eieio-defclass-autoload 'rudel-backend-factory 'nil "\
rudel-backend" "Factory class that holds an object for each known
backend\ncategory. Objects manage backend implementation for one backend\ncategory each.")
(defmacro rudel--with-memoization (place &rest code) (declare (indent 1)
(debug t)) (gv-letplace (getter setter) place `(or ,getter ,(macroexp-let2 nil val
(macroexp-progn code) `(progn ,(funcall setter val) ,val)))))
(cl-defmethod rudel-get-factory ((this (subclass rudel-backend-factory))
category) "\
Return the factory responsible for CATEGORY.
If there is no responsible factory, create one and return it."
(rudel--with-memoization (gethash category (eieio-oref-default this 'factories))
(make-instance 'rudel-backend-factory)))
but if you look at `rudel-backends.el` you'll see that this comes from:
things like:
;;;###rudel-autoload
(progn
(defmacro rudel--with-memoization (place &rest code)
(declare (indent 1) (debug t))
(gv-letplace (getter setter) place
`(or ,getter
,(macroexp-let2 nil val (macroexp-progn code)
`(progn
,(funcall setter val)
,val))))))
Where those `;;;###rudel-autoload` are used by Rudel's GNUmakefile to
build a `rudel-loaddefs.el` file (included in the tarball) but are not
supposed to make their way to `rudel-autoloads.el`.