[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#44149: 28.0.50; M-x finder-by-keyword, giving weird descriptions for
From: |
Stefan Kangas |
Subject: |
bug#44149: 28.0.50; M-x finder-by-keyword, giving weird descriptions for gnus and org |
Date: |
Mon, 26 Oct 2020 18:19:07 -0700 |
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...