bug#73792: 30; Confusion in loaddefs-generate--*-prefixes

[Jonas Bernoulli via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> loaddefs-generate--compute-prefixes ignores definitions with an
>> autoload cookie:
>>
>> ,----
>> |             (when (save-excursion
>> |                     (goto-char (match-beginning 0))
>> |                     (or (bobp)
>> |                         (progn
>> |                           (forward-line -1)
>> |                           (not (looking-at ";;;###autoload")))))
>> |               (push name prefs))))))
>> `----
>>
>> Why?!
>
> The "symbol prefix" machinery is designed so as to try and give easier
> access to those things that Emacs wouldn't know about with it
> (i.e. symbols that exist "out there" in some installed packaged but
> aren't yet represented in `obarray`).
>
> Autoloaded functions are presumably already represented in `obarray`
> even if the file hasn't yet been loaded.  Admittedly, this is not 100%
> sure, but that's the reason why the code thinks it can ignore them.
>
> As for "why bother", well it turns out that it's not completely uncommon
> for a package's autoloaded functions to fall outside of the prefix
> shared by all other definitions, so skipping them can help improve the
> prefix.  Examples would be `run-foo` commands where all other functions
> use the `foo-` prefix, or even just the common `foo` entry point where
> all other definitions use the `foo-` prefix.

Makes sense.

(I was looking at this code to see if it could be used for this other
use-case: collect all prefixes used by "all known" packages.  Such
a prefix-to-package mapping could be published and checked when new
packages are added to some *ELPA, to decrease the odds of conflicts
on the symbol level.

I had little hope that this code would be suitable for that use-case,
but it could have been, so I had a look.  And then I figured I might
as well report the comment issue and ask about this.

I won't be working on this any time soon, since I have too much on my
plate already.  So if anyone with time on their hands reads this and
thinks it is a good idea, please go ahead.)

     Jonas