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

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

[Gerard Vermeulen]

Hello,

I get the message:
"apropos-library: Wrong type argument: symbolp, ((cl-deftype-satisfies 
eglot-lsp-server))"
when I try "M-x apropos-library eglot"

GNU Emacs 30.0.60 (build 12, x86_64-apple-darwin20.6.0, NS 
appkit-2202.70 Version 11.7.1 (Build 20G918)) of 2024-08-13

Regards -- Gerard

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

[Eli Zaretskii]

> Date: Wed, 14 Aug 2024 08:04:31 +0000
> From: Gerard Vermeulen <gerard.vermeulen@posteo.net>
> 
> 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))

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

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.


        Stefan

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

[Eli Zaretskii]

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

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

In the mean time we could just sanitize the data we use heuristically,
as in the patch below.

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

Indeed, we currently don't have a good way to document the new kinds of
elements that can occur in `load-history` and the new ones we do have
(e.g. `cl-defmethod`, `define-type`, ...) are currently undocumented.


        Stefan


diff --git a/lisp/apropos.el b/lisp/apropos.el
index 6c6cd0b593d..0655fecd0e8 100644
--- a/lisp/apropos.el
+++ b/lisp/apropos.el
@@ -734,7 +734,10 @@ apropos-library
         ;; FIXME: Print information about each individual method: both
         ;; its docstring and specializers (bug#21422).
         ('cl-defmethod (push (cadr x) provides))
-	(_ (push (or (cdr-safe x) x) symbols))))
+        ;; FIXME: Add extension point (bug#72616).
+	(_ (let ((sym (or (cdr-safe x) x)))
+	     (and sym (symbolp sym)
+	          (push sym symbols))))))
     (let ((apropos-pattern "") ;Dummy binding for apropos-symbols-internal.
           (text
            (concat

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: gerard.vermeulen@posteo.net,  joaotavora@gmail.com,  72616@debbugs.gnu.org
> Date: Wed, 14 Aug 2024 08:47:40 -0400
> 
> >> 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?
> 
> In the mean time we could just sanitize the data we use heuristically,
> as in the patch below.

Thanks, will install soon unless someone has a better suggestion.

> > 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.)
> 
> Indeed, we currently don't have a good way to document the new kinds of
> elements that can occur in `load-history` and the new ones we do have
> (e.g. `cl-defmethod`, `define-type`, ...) are currently undocumented.

cl-defmethod and define-type _are_ documented, AFAICT.  See the
documentation of load-history.

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

[Eli Zaretskii]

> Cc: 72616@debbugs.gnu.org, gerard.vermeulen@posteo.net, joaotavora@gmail.com
> Date: Wed, 14 Aug 2024 16:41:19 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: gerard.vermeulen@posteo.net,  joaotavora@gmail.com,  72616@debbugs.gnu.org
> > Date: Wed, 14 Aug 2024 08:47:40 -0400
> > 
> > >> 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?
> > 
> > In the mean time we could just sanitize the data we use heuristically,
> > as in the patch below.
> 
> Thanks, will install soon unless someone has a better suggestion.

Now done.