bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails

bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails

[Mark Oteiza]

From emacs -Q:

M-x apropos-library RET cl-generic RET

Debugger entered--Lisp error: (wrong-type-argument symbolp (cl-generic-generalizers (head eql)))
  apropos-symbols-internal((cl--generic-typeof-generalizer cl--generic-typeof-types cl--generic-struct-generalizer cl--generic-struct-specializers cl--generic$
  apropos-library("cl-generic")
  funcall-interactively(apropos-library "cl-generic")
  call-interactively(apropos-library record nil)
  command-execute(apropos-library record)
  execute-extended-command(nil "apropos-library" nil)
  funcall-interactively(execute-extended-command nil "apropos-library" nil)
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

I came across this because doing M-. on a function defined with
cl-defgeneric and cl-defmethod doesn't go to the definition, just the
top of the library, so apropos-library was my backup. I don't know if
the xref behavior should be a separate report.

bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails

[Mark Oteiza]

On 05/09/15 at 12:58am, Mark Oteiza wrote:
> 
> From emacs -Q:
> 
> M-x apropos-library RET cl-generic RET
> 
> Debugger entered--Lisp error: (wrong-type-argument symbolp (cl-generic-generalizers (head eql)))
>   apropos-symbols-internal((cl--generic-typeof-generalizer cl--generic-typeof-types cl--generic-struct-generalizer cl--generic-struct-specializers cl--generic$
>   apropos-library("cl-generic")
>   funcall-interactively(apropos-library "cl-generic")
>   call-interactively(apropos-library record nil)
>   command-execute(apropos-library record)
>   execute-extended-command(nil "apropos-library" nil)
>   funcall-interactively(execute-extended-command nil "apropos-library" nil)
>   call-interactively(execute-extended-command nil nil)
>   command-execute(execute-extended-command)
> 
> I came across this because doing M-. on a function defined with
> cl-defgeneric and cl-defmethod doesn't go to the definition, just the
> top of the library, so apropos-library was my backup. I don't know if
> the xref behavior should be a separate report.

cl-generic is used pretty widely, and apropos-library fails on libraries
using it. Could this be marked to be fixed before release?

bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails

[Eli Zaretskii]

> Date: Thu, 7 Jan 2016 14:06:40 -0500
> From: Mark Oteiza <mvoteiza@udel.edu>
> 
> >   apropos-library("cl-generic")
> >   funcall-interactively(apropos-library "cl-generic")
> >   call-interactively(apropos-library record nil)
> >   command-execute(apropos-library record)
> >   execute-extended-command(nil "apropos-library" nil)
> >   funcall-interactively(execute-extended-command nil "apropos-library" nil)
> >   call-interactively(execute-extended-command nil nil)
> >   command-execute(execute-extended-command)
> > 
> > I came across this because doing M-. on a function defined with
> > cl-defgeneric and cl-defmethod doesn't go to the definition, just the
> > top of the library, so apropos-library was my backup. I don't know if
> > the xref behavior should be a separate report.
> 
> cl-generic is used pretty widely, and apropos-library fails on libraries
> using it. Could this be marked to be fixed before release?

IMO, we should only do that if it's practical, i.e. if there's someone
who would work on fixing that.

I'd also suggest to have bug#22294 be the release blocker, if we have
a volunteer to work on it.

bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails

[Dmitry Gutov]

On 01/07/2016 11:06 PM, Eli Zaretskii wrote:

>>> I came across this because doing M-. on a function defined with
>>> cl-defgeneric and cl-defmethod doesn't go to the definition, just the
>>> top of the library, so apropos-library was my backup. I don't know if
>>> the xref behavior should be a separate report.

FWIW, this has worked for some time now.

M-x describe-function is another way to find the generic definitions.

> IMO, we should only do that if it's practical, i.e. if there's someone
> who would work on fixing that.
>
> I'd also suggest to have bug#22294 be the release blocker, if we have
> a volunteer to work on it.

(Not a volunteer on either.) I've pushed a minor fix for this bug, to 
avoid the error. The description buffer now shows duplicates, though, 
instead of proper info about specialized methods.

bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails

[Glenn Morris]

The root cause is that 24b7f77 puts non-standard entries in load-history
("Record manually in the load-history").

If that's really the way it's going to be, it needs an "incompatible
change" NEWS entry and doc updates (the format of a load-history entry
is documented in the elisp manual). These new cl-defmethod entries don't
match the documented format.

bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails

[Glenn Morris]

Eli Zaretskii wrote:

>> cl-generic is used pretty widely, and apropos-library fails on libraries
>> using it. Could this be marked to be fixed before release?
>
> IMO, we should only do that if it's practical, i.e. if there's someone
> who would work on fixing that.

I don't think that's the right approach.

One purpose of marking things as release blockers is to encourage
people to work on them. The list is not set in stone. I expect that
close to the release, some will remain unfixed and will be
intentionally ignored/unblocked. The decision about what to mark as a
blocker shouldn't be based on manpower (at this stage), it should be
based on what the ideal 25.1 should look like.

> I'd also suggest to have bug#22294 be the release blocker, [...]

You don't need to suggest it, please just do it.
It would be great if the list of blocking bugs became something other
than just my own opinion.

bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Mark Oteiza <mvoteiza@udel.edu>,  21422@debbugs.gnu.org
> Date: Thu, 07 Jan 2016 20:27:57 -0500
> 
> Eli Zaretskii wrote:
> 
> >> cl-generic is used pretty widely, and apropos-library fails on libraries
> >> using it. Could this be marked to be fixed before release?
> >
> > IMO, we should only do that if it's practical, i.e. if there's someone
> > who would work on fixing that.
> 
> I don't think that's the right approach.
> 
> One purpose of marking things as release blockers is to encourage
> people to work on them.

Sure, provided that there's someone who can be encouraged.  Otherwise,
it's futile, isn't it?

But I didn't write what you cite above as a general proposal.  I wrote
that specifically about this kind of bugs: I find it hard to believe
that we would consider such bugs critical, i.e. something with which
it would be unthinkable to release Emacs.  You need to read what I
wrote keeping this in mind, and without generalizing it to any other
kind of bugs, particularly those that are really critical ones.

> > I'd also suggest to have bug#22294 be the release blocker, [...]
> 
> You don't need to suggest it, please just do it.

If #21422 is marked as a blocker, I will do the same for #22294.  They
are in the same boat: extremely inconvenient, but not really critical.

> It would be great if the list of blocking bugs became something other
> than just my own opinion.

It stopped being just your own option long ago.  I'm using it, for
one.

Thanks.

bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Mark Oteiza <mvoteiza@udel.edu>,  21422@debbugs.gnu.org, Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 07 Jan 2016 20:27:49 -0500
> 
> 
> The root cause is that 24b7f77 puts non-standard entries in load-history
> ("Record manually in the load-history").
> 
> If that's really the way it's going to be, it needs an "incompatible
> change" NEWS entry and doc updates (the format of a load-history entry
> is documented in the elisp manual). These new cl-defmethod entries don't
> match the documented format.

Could you please update the documentation according to the above?
Thanks.

bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails

[Glenn Morris]

Eli Zaretskii wrote:

> Could you please update the documentation according to the above?

Sorry, no. (I've had enough of documenting other people's work for them.)

bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails

[Glenn Morris]

Eli Zaretskii wrote:

>> It would be great if the list of blocking bugs became something other
>> than just my own opinion.
>
> It stopped being just your own option long ago.  I'm using it, for
> one.

That's nice to hear, although when I look at http://debbugs.gnu.org/19759
(which is coming up on its one-year anniversary), all changes are mine,
except one, by you, a week ago. So we either aren't talking about the
same thing, or have very different definitions of "long ago".

bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 21422@debbugs.gnu.org
> Date: Fri, 08 Jan 2016 19:44:46 -0500
> 
> Eli Zaretskii wrote:
> 
> >> It would be great if the list of blocking bugs became something other
> >> than just my own opinion.
> >
> > It stopped being just your own option long ago.  I'm using it, for
> > one.
> 
> That's nice to hear, although when I look at http://debbugs.gnu.org/19759
> (which is coming up on its one-year anniversary), all changes are mine,
> except one, by you, a week ago. So we either aren't talking about the
> same thing, or have very different definitions of "long ago".

Why do you dismiss that single use by me?  It clearly says that I use
the facility when I think it's appropriate, doesn't it?