bug#72616: 30.0.60; M-x apropos-library eglot fails

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Gerard Vermeulen <gerard.vermeulen@posteo.net>,  João Távora
>  <joaotavora@gmail.com>,  72616@debbugs.gnu.org
> Date: Wed, 14 Aug 2024 07:58:15 -0400
> 
> >> I get the message:
> >> "apropos-library: Wrong type argument: symbolp, ((cl-deftype-satisfies 
> >> eglot-lsp-server))"
> >> when I try "M-x apropos-library eglot"
> >
> > You forgot to tell that one needs first to load Eglot, otherwise the
> > above command cannot be invoked at all.
> >
> > Stefan and João, is the below the right solution?
> >
> > diff --git a/lisp/apropos.el b/lisp/apropos.el
> > index 6c6cd0b..3fb7581 100644
> > --- a/lisp/apropos.el
> > +++ b/lisp/apropos.el
> > @@ -731,6 +731,7 @@ apropos-library
> >  	('require (push (cdr x) requires))
> >  	('provide (push (cdr x) provides))
> >          ('t nil)                     ; Skip "was an autoload" entries.
> > +        ('define-symbol-props nil)
> >          ;; FIXME: Print information about each individual method: both
> >          ;; its docstring and specializers (bug#21422).
> >          ('cl-defmethod (push (cadr x) provides))
> 
> This doesn't look right: the meaning of `define-symbol-props` in
> `load-history` should be defined in a more modular way, near
> `define-symbol-prop` rather than by hardcoding something in
> `apropos.el`.

Is it better to leave us where we are now: that apropos-library
signals an error instead of displaying the information about the
library?

> IOW, we should add something to `apropos.el` where users of
> `load-history` can register what to do with their entries, just like
> `find-function-regexp-alist` and the generic function
> `loadhist-unload-element` are used to tell `find-function` what to do
> with those same entries.

Patches are welcome, but maybe we should start with someone explaining
what are those define-symbol-props elements in load-history.  They are
currently completely undocumented AFAICT, and so anyone but the
person(s) who added that to Emacs will have hard time coming up with
changes such as you describe.  (Apologies if this is already
documented and I just missed it.)