bug#44149: 28.0.50; M-x finder-by-keyword, giving weird descriptions for gnus and org

[Stefan Kangas]

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

>>> Just tell me if it is a joke that gnus is described this way.
>>> gnus 5.13 built-in Identifying spam
>> The description comes from spam.el:
>> ./spam.el:1:;;; spam.el --- Identifying spam
>
> But why is it put under the name "gnus"?
[...]
> Similarly, why is it put under the name "org"?

See my analysis below.

>>       * lisp/finder.el (finder-compile-keywords): Grab version from
>>       package--builtin-versions when available.
>>
>> It makes "(or (eq base-name package) version)" below that always be true,
>
> I don't understand why it does that.

The reason is that the local variable `version' is now always set for
any file belonging to a built-in package.  From your patch:

            (setq version (or (ignore-errors (version-to-list version))
                              (alist-get package package--builtin-versions)))

We decide if a file belongs to a package based on if it is in a
directory, so for any file "org/*.el" the local `package' variable will
be the symbol `org'.

A few lines down, we do this:

                  ;; The idea here is that eg calc.el gets to define
                  ;; the description of the calc package.
                  ;; This does not work for eg nxml-mode.el.
                  ((or (eq base-name package) version)
                   (setq desc (cdr entry))
                   (aset desc 0 version)
                   (aset desc 2 summary)))

So, for example, we evaluate (or (eq base-name package) version) for
"ox.el" with the following variables:

    base-name:  'org
    package:    'ox
    version:    (alist-get 'org package--builtin-versions) => (9 3)

So `version' is set for all files "org/*.el", and the package
description will now be set to whatever is used in "ox.el" (since it is
the last file alphabetically).

>> Reverting the above commit fixes this issue here.
>
> I get the impression that there's some other underlying problem.
>
>> I'm not sure how best to fix this without breaking something else.
>> Perhaps Stefan M has an idea?
>
> I don't understand this code enough to give much guidance, I'm afraid.

I also feel a bit stuck...