* bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails
@ 2015-09-05 4:58 Mark Oteiza
2016-01-07 19:06 ` Mark Oteiza
0 siblings, 1 reply; 11+ messages in thread
From: Mark Oteiza @ 2015-09-05 4:58 UTC (permalink / raw)
To: 21422
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.
^ permalink raw reply [flat|nested] 11+ messages in thread* bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails
2015-09-05 4:58 bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails Mark Oteiza
@ 2016-01-07 19:06 ` Mark Oteiza
2016-01-07 20:06 ` Eli Zaretskii
0 siblings, 1 reply; 11+ messages in thread
From: Mark Oteiza @ 2016-01-07 19:06 UTC (permalink / raw)
To: 21422
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?
^ permalink raw reply [flat|nested] 11+ messages in thread* bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails
2016-01-07 19:06 ` Mark Oteiza
@ 2016-01-07 20:06 ` Eli Zaretskii
2016-01-07 23:35 ` Dmitry Gutov
2016-01-08 1:27 ` Glenn Morris
0 siblings, 2 replies; 11+ messages in thread
From: Eli Zaretskii @ 2016-01-07 20:06 UTC (permalink / raw)
To: Mark Oteiza; +Cc: 21422
> 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.
^ permalink raw reply [flat|nested] 11+ messages in thread* bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails
2016-01-07 20:06 ` Eli Zaretskii
@ 2016-01-07 23:35 ` Dmitry Gutov
2016-01-08 1:27 ` Glenn Morris
2016-01-08 1:27 ` Glenn Morris
1 sibling, 1 reply; 11+ messages in thread
From: Dmitry Gutov @ 2016-01-07 23:35 UTC (permalink / raw)
To: Eli Zaretskii, Mark Oteiza; +Cc: 21422
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.
^ permalink raw reply [flat|nested] 11+ messages in thread* bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails
2016-01-07 23:35 ` Dmitry Gutov
@ 2016-01-08 1:27 ` Glenn Morris
2016-01-08 12:14 ` Eli Zaretskii
0 siblings, 1 reply; 11+ messages in thread
From: Glenn Morris @ 2016-01-08 1:27 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Mark Oteiza, 21422, Dmitry Gutov
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.
^ permalink raw reply [flat|nested] 11+ messages in thread* bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails
2016-01-08 1:27 ` Glenn Morris
@ 2016-01-08 12:14 ` Eli Zaretskii
2016-01-09 0:44 ` Glenn Morris
0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2016-01-08 12:14 UTC (permalink / raw)
To: Glenn Morris; +Cc: mvoteiza, monnier, 21422, dgutov
> 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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails
2016-01-07 20:06 ` Eli Zaretskii
2016-01-07 23:35 ` Dmitry Gutov
@ 2016-01-08 1:27 ` Glenn Morris
2016-01-08 9:36 ` Eli Zaretskii
1 sibling, 1 reply; 11+ messages in thread
From: Glenn Morris @ 2016-01-08 1:27 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Mark Oteiza, 21422
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.
^ permalink raw reply [flat|nested] 11+ messages in thread* bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails
2016-01-08 1:27 ` Glenn Morris
@ 2016-01-08 9:36 ` Eli Zaretskii
2016-01-09 0:44 ` Glenn Morris
0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2016-01-08 9:36 UTC (permalink / raw)
To: Glenn Morris; +Cc: mvoteiza, 21422
> 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.
^ permalink raw reply [flat|nested] 11+ messages in thread* bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails
2016-01-08 9:36 ` Eli Zaretskii
@ 2016-01-09 0:44 ` Glenn Morris
2016-01-09 7:05 ` Eli Zaretskii
0 siblings, 1 reply; 11+ messages in thread
From: Glenn Morris @ 2016-01-09 0:44 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 21422
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".
^ permalink raw reply [flat|nested] 11+ messages in thread* bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails
2016-01-09 0:44 ` Glenn Morris
@ 2016-01-09 7:05 ` Eli Zaretskii
0 siblings, 0 replies; 11+ messages in thread
From: Eli Zaretskii @ 2016-01-09 7:05 UTC (permalink / raw)
To: Glenn Morris; +Cc: 21422
> 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?
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2016-01-09 7:05 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-09-05 4:58 bug#21422: 25.0.50; apropos-library on libraries using cl-def{generic,method} fails Mark Oteiza
2016-01-07 19:06 ` Mark Oteiza
2016-01-07 20:06 ` Eli Zaretskii
2016-01-07 23:35 ` Dmitry Gutov
2016-01-08 1:27 ` Glenn Morris
2016-01-08 12:14 ` Eli Zaretskii
2016-01-09 0:44 ` Glenn Morris
2016-01-08 1:27 ` Glenn Morris
2016-01-08 9:36 ` Eli Zaretskii
2016-01-09 0:44 ` Glenn Morris
2016-01-09 7:05 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).