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

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

[Jean Louis]

Just tell me if it is a joke that gnus is described this way.

gnus 5.13 built-in Identifying spam (this description is not
reasonable and also not user friendly)

Another issue, Org is described as:

org 9.3 built-in Export Framework for Org Mode

Then if I click on org I can get description about Org mode. It is
definitely confusing, as it is either export framework for Org Mode or
Org mode.



In GNU Emacs 28.0.50 (build 18, x86_64-pc-linux-gnu, GTK+ Version 3.22.12, cairo version 1.14.8)
 of 2020-10-14 built on protected.rcdrun.com
Repository revision: 423439b38067c4a428310edab24fba7da082027c
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11907000
System Description: Hyperbola GNU/Linux-libre

Configured using:
 'configure --prefix=/package/text/emacs-2020-10-14 --with-modules'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS JSON PDUMPER LCMS2

Important settings:
  value of $LC_ALL: de_DE.UTF-8
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: @im=exwm-xim
  locale-coding-system: utf-8-unix

Major mode: Package Menu

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort hashcash mail-extr emacsbug message rmc puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg epg-config gnus-util
rmail rmail-loaddefs text-property-search mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date noutline
outline easy-mmode jka-compr help-mode finder finder-inf find-func
lisp-mnt package easymenu browse-url url-handlers url-parse auth-source
cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json
subr-x map url-vars seq byte-opt gv bytecomp byte-compile cconv
cl-loaddefs cl-lib tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 68473 6167)
 (symbols 48 8592 1)
 (strings 32 23371 1336)
 (string-bytes 1 747364)
 (vectors 16 13701)
 (vector-slots 8 185743 8830)
 (floats 8 31 250)
 (intervals 56 535 14)
 (buffers 992 15))

-- 
Thanks,
Jean Louis

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

[Stefan Kangas]

Jean Louis <bugs@gnu.support> 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

> Another issue, Org is described as:
>
> org 9.3 built-in Export Framework for Org Mode

This description comes from ox.el

./ox.el:1:;;; ox.el --- Export Framework for Org Mode [...]

> Then if I click on org I can get description about Org mode. It is
> definitely confusing, as it is either export framework for Org Mode or
> Org mode.

This can be seen in `list-packages', or by evaluating
`(assq 'org package--builtins)'.

This is due to `finder-compile-keywords' that creates the file
lisp/finder-inf.el, and it seems like this bug was introduced by commit
851535f587:

  commit 851535f58745dcfbc8798b3a34b4fea852f93a3e
  Author: Stefan Monnier <monnier@iro.umontreal.ca>
  Date:   Sat Jul 6 18:42:02 2019 -0400

      * lisp/emacs-lisp/nadvice.el: Make it a package separate from `emacs`.

      * 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, and so we use whatever file comes alphabetically last as the name
of a package (above, that happens to be "spam.el" and "ox.el").

Reverting the above commit fixes this issue here.

I'm not sure how best to fix this without breaking something else.
Perhaps Stefan M has an idea?

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

[Stefan Monnier]

>> 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"?

>> Another issue, Org is described as:
>> org 9.3 built-in Export Framework for Org Mode
> This description comes from ox.el
> ./ox.el:1:;;; ox.el --- Export Framework for Org Mode [...]

Similarly, why is it put under the name "org"?

>   commit 851535f58745dcfbc8798b3a34b4fea852f93a3e
>   Author: Stefan Monnier <monnier@iro.umontreal.ca>
>   Date:   Sat Jul 6 18:42:02 2019 -0400
>
>       * lisp/emacs-lisp/nadvice.el: Make it a package separate from `emacs`.
>
>       * 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.

> 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.


        Stefan

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...

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

[Stefan Monnier]

> 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'.

And here again, I wonder why.  Isn't it the source of our problems?


        Stefan