Subject: bug#63480: 30.0.50; [BUG] unimplemented logic regarding read-symbol-shorthands

From: Joseph Turner <[email-masked]>
Date: Tue, 28 Nov 2023 23:45:18 -0800

From: Stefan Kangas <[email-masked]>

> João Távora <[email-masked]> writes:

> > This is a duplicate of
> >
> >    https://github.com/joaotavora/breadcrumb/issues/3
> >
> > which has already been solved.  I updated the autoloads to use
> > longhand versions already a couple of months ago.

> OK, thanks.

> > I'll leave it to you if this issue can be closed or not.

> I guess the issue here is what you describe below?  If so, I guess it
> should remain open until it is fixed.

> > Anyway, the problem with shorthands and autoloads remains.
> > The GitHub user 'dickmao' proposed a patch there, which I
> > didn't test, but I attach here.
> >
> > My idea for an alternative patch would be for the "autoload
> > extractor" (which I'm not familiar with) to see the shorthand
> > autoload but place it in longhand form in the generated
> > autoloads file.  I don't have a patch for that idea,
> > unfortunately.

This bug affects not only autoloaded function definitions, but any
autoloaded form.  For example, the following will not generate the
correct autoloads:

;;;###autoload
(with-eval-after-load 'optional-dependency
  (cl-pushnew 'sns-var optional-dependency-var))

Instead, you must expand the shorthand symbol into its full form:

;;;###autoload
(with-eval-after-load 'optional-dependency
  (cl-pushnew 'some-nice-string-utils-var optional-dependency-var))

For a real-world example, see

https://git.sr.ht/~ushin/hyperdrive.el/commit/48afc51ac22713f2c54f75a7ea3b5c6b0e12b53d

Thank you!

Joseph