bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Bob Rogers]

   1.  In a top-level directory with Perl modules ("*.pm") underneath,
create an etags file that indexes the modules, e.g.

	find . -type f -name '*.pm' | etags -

   2.  Invoke "emacs -Q" in this directory.

   3.  "M-x visit-tags-table RET RET"

   4.  "M-. perl_method_name RET" where "perl_method_name" is known to
be defined.

The bug is that, no matter how many perl_method_name definitions exist
in the TAGS file, xref-find-definitions won't find any of them, because
it's only looking for an exact match to what Perl considers the
package-qualified name, namely the "Perl::Package::perl_method_name" as
it appears in this TAGS line:

	sub perl_method_name ^?Perl::Package::perl_method_name^A23,321

FWIW, the patch I have included below "================" papers over the
problem (though it's clearly much too kludgy to apply).

Note that this has also been failing in master for some time now; sorry
I didn't report it sooner.

					-- Bob Rogers
					   http://www.rgrjr.com/

------------------------------------------------------------------------
Configured using:
 'configure --with-pop --without-dbus --prefix=/usr
 --infodir=/usr/share/info --mandir=/usr/share/man
 --sharedstatedir=/var/lib --libexecdir=/usr/lib --with-x --with-xpm=no
 --with-jpeg --with-tiff --with-gif=no --with-png --with-x-toolkit=yes
 --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib64 --build
 x86_64-suse-linux 'CFLAGS=-g -O2 -fno-optimize-sibling-calls'
 LDFLAGS=-s'

Configured features:
JPEG TIFF PNG RSVG SOUND GSETTINGS NOTIFY FREETYPE XFT ZLIB
TOOLKIT_SCROLL_BARS GTK2 X11

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

================

diff -u --label /usr/share/emacs/25.0.92/lisp/progmodes/etags.el.gz --label \#\<buffer\ etags.el.gz\> /tmp/rogers/jka-com1969tT2 /tmp/rogers/buffer-content-1969snL
--- /usr/share/emacs/25.0.92/lisp/progmodes/etags.el.gz
+++ #<buffer etags.el.gz>
@@ -1617,7 +1617,11 @@
   (or (and (eq (char-after (point)) ?\001)
 	   (eq (char-after (- (point) (length tag) 1)) ?\177))
       ;; We are not on the explicit tag name, but perhaps it follows.
-      (looking-at (concat "[^\177\n]*\177" (regexp-quote tag) "\001"))))
+      (looking-at (concat "[^\177\n]*\177" (regexp-quote tag) "\001"))
+      ;; This works for perl.  -- rgr, 8-Mar-16.
+      (save-excursion
+	(skip-chars-backward "^:\n")
+	(looking-at (concat (regexp-quote tag) "\001")))))
 
 ;; t if point is at a tag line that has an implicit name.
 ;; point should be just after a string that matches TAG.

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Dmitry Gutov]

Hi Bob,

On 03/08/2016 08:27 PM, Bob Rogers wrote:

> The bug is that, no matter how many perl_method_name definitions exist
> in the TAGS file, xref-find-definitions won't find any of them, because
> it's only looking for an exact match to what Perl considers the
> package-qualified name, namely the "Perl::Package::perl_method_name" as
> it appears in this TAGS line:
>
> 	sub perl_method_name ^?Perl::Package::perl_method_name^A23,321

This seems to indicate a problem in etags. Were you using the "real" 
etags, one that's developed and distributed together with Emacs? Did it 
come with the development snapshot your bug report was sent from?

If so, please send a small sample of Perl code we can reproduce the 
problem in.

> FWIW, the patch I have included below "================" papers over the
> problem (though it's clearly much too kludgy to apply).

Thanks, but yes, that patch is a kludge.

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Bob Rogers]

   From: Dmitry Gutov <dgutov@yandex.ru>
   Date: Wed, 9 Mar 2016 03:52:43 +0200

   Hi Bob,

   On 03/08/2016 08:27 PM, Bob Rogers wrote:

   > The bug is that, no matter how many perl_method_name definitions exist
   > in the TAGS file, xref-find-definitions won't find any of them, because
   > it's only looking for an exact match to what Perl considers the
   > package-qualified name, namely the "Perl::Package::perl_method_name" as
   > it appears in this TAGS line:
   >
   > 	sub perl_method_name ^?Perl::Package::perl_method_name^A23,321

   This seems to indicate a problem in etags. Were you using the "real" 
   etags, one that's developed and distributed together with Emacs? Did it 
   come with the development snapshot your bug report was sent from?

Yes, and yes.

   If so, please send a small sample of Perl code we can reproduce the 
   problem in.

Try this:

   1.  git clone git@github.com:rgrjr/meals.git

   2.  cd meals

   3.  etags *.pl

and then continue with step two in the original recipe.  (This is a
small hack; the clone should only be half a megabyte.)  You can try
M-. on parse_recipes (one definition) or add_ingredient (two
definitions).

					-- Bob

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Eli Zaretskii]

> From: Bob Rogers <rogers@modulargenetics.com>
> Date: Tue, 8 Mar 2016 21:43:48 -0500
> Cc: 22947@debbugs.gnu.org
> 
>    If so, please send a small sample of Perl code we can reproduce the 
>    problem in.
> 
> Try this:
> 
>    1.  git clone git@github.com:rgrjr/meals.git
> 
>    2.  cd meals
> 
>    3.  etags *.pl
> 
> and then continue with step two in the original recipe.  (This is a
> small hack; the clone should only be half a megabyte.)  You can try
> M-. on parse_recipes (one definition) or add_ingredient (two
> definitions).

Dmitry,

Is there something that should be done in etags for this issue?  If
so, what?

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Dmitry Gutov]

On 03/10/2016 03:20 PM, Eli Zaretskii wrote:

> Is there something that should be done in etags for this issue?  If
> so, what?

The usual, I think: Bob is searching for perl_method_name, but the 
entries in TAGS have names like Perl::Package::perl_method_name.

So we need to generate unqualified tag names, in addition to (or simply 
instead of) the qualified ones like the above.

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Eli Zaretskii]

> Cc: 22947@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 10 Mar 2016 15:36:58 +0200
> 
> So we need to generate unqualified tag names, in addition to (or simply 
> instead of) the qualified ones like the above.

So which one is better: both unqualified and qualified, or just
unqualified?

What symbol does xref pick up in a Perl buffer, when we have a
qualified name at point?

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Dmitry Gutov]

On 03/10/2016 04:16 PM, Eli Zaretskii wrote:

> So which one is better: both unqualified and qualified, or just
> unqualified?

We've had this discussion before: including the qualified names 
increases the size of the table, but allows the user to pick the 
qualified name if they don't mind typing it in the prompt, with completion.

It's a tradeoff. "No qualified names" is probably a better default, 
because the user needs extra knowledge to make use of them. So they 
might as well have to find out how to turn them on.

> What symbol does xref pick up in a Perl buffer, when we have a
> qualified name at point?

Like in other languages, the unqualified one (most of the time).

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Eli Zaretskii]

> Cc: 22947@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 10 Mar 2016 15:36:58 +0200
> 
> On 03/10/2016 03:20 PM, Eli Zaretskii wrote:
> 
> > Is there something that should be done in etags for this issue?  If
> > so, what?
> 
> The usual, I think: Bob is searching for perl_method_name, but the 
> entries in TAGS have names like Perl::Package::perl_method_name.
> 
> So we need to generate unqualified tag names, in addition to (or simply 
> instead of) the qualified ones like the above.

I decided to go the same way as with C-like languages: by default
produce unqualified tag names, unless -Q was specified.

Bob, can you try etags from the latest emacs-25 branch?  I tried your
recipe, and it seems to work well with "meals", but I'm not a power
Perl user, so maybe there's some left-overs that we need to handle.

Thanks.

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Dmitry Gutov]

On 03/10/2016 05:31 PM, Eli Zaretskii wrote:

> I decided to go the same way as with C-like languages: by default
> produce unqualified tag names, unless -Q was specified.

Does calling etags '-Q' result in it producing *only* qualified names? 
That doesn't sound very useful.

Do you expect the user to call 'etags' twice, with and without 'Q', and 
append the outputs?

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Eli Zaretskii]

> Cc: 22947@debbugs.gnu.org, rogers@modulargenetics.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 10 Mar 2016 17:50:37 +0200
> 
> On 03/10/2016 05:31 PM, Eli Zaretskii wrote:
> 
> > I decided to go the same way as with C-like languages: by default
> > produce unqualified tag names, unless -Q was specified.
> 
> Does calling etags '-Q' result in it producing *only* qualified names? 

Yes.

> That doesn't sound very useful.

Then users will not use that switch.  And note that before these
changes, etags would _always_ produce only qualified names.  So the -Q
switch provides a way to get the old behavior back.

> Do you expect the user to call 'etags' twice, with and without 'Q', and 
> append the outputs?

No, I think qualified names are almost never useful, given the way
TAGS tables are used in Emacs nowadays, so the -Q option is just a
kind of "fire escape" for use cases that I think should never happen.

If I'm wrong, then I'd like to see these use cases described, and we
should then rethink the whole issue of qualified tag names.

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Dmitry Gutov]

On 03/10/2016 06:22 PM, Eli Zaretskii wrote:

> Then users will not use that switch.  And note that before these
> changes, etags would _always_ produce only qualified names.  So the -Q
> switch provides a way to get the old behavior back.

Honestly, I didn't use the "before" etags much. I did use 'ctags -e', 
however. I imagine many users will be in a similar position.

ctags has had the --extra=+q option for years (although it's worked only 
for a few languages). So if we're asking for arguments, they should be 
for why deviate, rather than why do the same, the latter being the 
default choice. And yes, users do want those:

https://github.com/universal-ctags/ctags/issues/787
https://github.com/universal-ctags/ctags/issues/524

>> Do you expect the user to call 'etags' twice, with and without 'Q', and
>> append the outputs?
>
> No, I think qualified names are almost never useful, given the way
> TAGS tables are used in Emacs nowadays, so the -Q option is just a
> kind of "fire escape" for use cases that I think should never happen.
>
> If I'm wrong, then I'd like to see these use cases described, and we
> should then rethink the whole issue of qualified tag names.

Here's a couple of scenarios:

1. Suppose there are a lot of classes that define the method bar. But I 
know which class I'm interested in. So I type C-u M-., type 
My::Class#bar, and jump to it straight away (typing it with completion 
might be rather quick). If the tags file contains only unqualified 
entries, I'm forced to see the whole list of methods with this name in 
all classes, use isearch to go to the desired entry, press RET to jump 
to it, and then do something about the xref window (I didn't need to see 
the whole list in the first place, and it's taking up valuable screen 
estate). More keypresses and micromanagement this way.

2. Suppose I want to see all methods defined by the class Foo. I can 
call xref-find-apropos, type in the class name, and if these is a fully 
qualified entry for each of its methods in the tags table, I'll see them 
all in the list. Or I want to see all methods in a family of classes 
(unified by a namespace, or a common word in the name). Having all 
qualified names listed would facilitate this kind of exploration.

Users shouldn't have to give up having functional xref-find-definitions 
for these features.

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Eli Zaretskii]

> Cc: 22947@debbugs.gnu.org, rogers@modulargenetics.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 11 Mar 2016 03:45:39 +0200
> 
> On 03/10/2016 06:22 PM, Eli Zaretskii wrote:
> 
> > Then users will not use that switch.  And note that before these
> > changes, etags would _always_ produce only qualified names.  So the -Q
> > switch provides a way to get the old behavior back.
> 
> Honestly, I didn't use the "before" etags much. I did use 'ctags -e', 
> however. I imagine many users will be in a similar position.
> 
> ctags has had the --extra=+q option for years (although it's worked only 
> for a few languages). So if we're asking for arguments, they should be 
> for why deviate, rather than why do the same, the latter being the 
> default choice. And yes, users do want those:
> 
> https://github.com/universal-ctags/ctags/issues/787
> https://github.com/universal-ctags/ctags/issues/524
> 
> >> Do you expect the user to call 'etags' twice, with and without 'Q', and
> >> append the outputs?
> >
> > No, I think qualified names are almost never useful, given the way
> > TAGS tables are used in Emacs nowadays, so the -Q option is just a
> > kind of "fire escape" for use cases that I think should never happen.
> >
> > If I'm wrong, then I'd like to see these use cases described, and we
> > should then rethink the whole issue of qualified tag names.
> 
> Here's a couple of scenarios:
> 
> 1. Suppose there are a lot of classes that define the method bar. But I 
> know which class I'm interested in. So I type C-u M-., type 
> My::Class#bar, and jump to it straight away (typing it with completion 
> might be rather quick). If the tags file contains only unqualified 
> entries, I'm forced to see the whole list of methods with this name in 
> all classes, use isearch to go to the desired entry, press RET to jump 
> to it, and then do something about the xref window (I didn't need to see 
> the whole list in the first place, and it's taking up valuable screen 
> estate). More keypresses and micromanagement this way.
> 
> 2. Suppose I want to see all methods defined by the class Foo. I can 
> call xref-find-apropos, type in the class name, and if these is a fully 
> qualified entry for each of its methods in the tags table, I'll see them 
> all in the list. Or I want to see all methods in a family of classes 
> (unified by a namespace, or a common word in the name). Having all 
> qualified names listed would facilitate this kind of exploration.
> 
> Users shouldn't have to give up having functional xref-find-definitions 
> for these features.

Etags never had these features, so you are asking for enhancements.  I
suggest to file a separate wishlist bug report with these requests,
and maybe Someone will implement them at some point.

Note that adding such a feature would mean extending the generation of
class-qualified names to all the languages which have a notion of a
class or a package, so it's not a small job, and requires to have a
good understanding of many languages.

Personally, I'd like first to see if the current implementation of
etags + xref gives good results, before considering enhancements.
Without seeing user responses, we will never know how important these
features are.

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Dmitry Gutov]

On 03/11/2016 10:04 AM, Eli Zaretskii wrote:

> Etags never had these features, so you are asking for enhancements.  I
> suggest to file a separate wishlist bug report with these requests,
> and maybe Someone will implement them at some point.

There's nothing to implement in Emacs, both of these scenarios should 
work already. They just need the presence of qualified names in the tags 
table.

And allowing the output of qualified+unqualified, in etags, doesn't seem 
like a huge job to me.

> Note that adding such a feature would mean extending the generation of
> class-qualified names to all the languages which have a notion of a
> class or a package, so it's not a small job, and requires to have a
> good understanding of many languages.

We can perfectly well choose to support this feature only for a few 
languages. It's better than nothing.

Here's the relevant excerpt from ctags's manpage:

"""
q

Include an extra class-qualified tag entry for each tag which is a 
member of a class (for languages for which this information is 
extracted; currently C++, Eiffel, and Java). The actual form of the 
qualified tag depends upon the language from which the tag was derived 
(using a form that is most natural for how qualified calls are specified 
in the language). For C++, it is in the form "class::member"; for Eiffel 
and Java, it is in the form "class.member". This may allow easier 
location of a specific tags when multiple occurrences of a tag name 
occur in the tag file. Note, however, that this could potentially more 
than double the size of the tag file.
"""

> Personally, I'd like first to see if the current implementation of
> etags + xref gives good results, before considering enhancements.
> Without seeing user responses, we will never know how important these
> features are.

Ultimately, it's your choice, of course.

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Eli Zaretskii]

> Cc: 22947@debbugs.gnu.org, rogers@modulargenetics.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 11 Mar 2016 14:46:25 +0200
> 
> On 03/11/2016 10:04 AM, Eli Zaretskii wrote:
> 
> > Etags never had these features, so you are asking for enhancements.  I
> > suggest to file a separate wishlist bug report with these requests,
> > and maybe Someone will implement them at some point.
> 
> There's nothing to implement in Emacs, both of these scenarios should 
> work already.

I said "etags", not "emacs".

> And allowing the output of qualified+unqualified, in etags, doesn't seem 
> like a huge job to me.

For languages where qualified tags are already created, maybe.
(C-like languages might be not so easy, due to the state machines they
use.)  But are we sure all languages do?

> > Note that adding such a feature would mean extending the generation of
> > class-qualified names to all the languages which have a notion of a
> > class or a package, so it's not a small job, and requires to have a
> > good understanding of many languages.
> 
> We can perfectly well choose to support this feature only for a few 
> languages. It's better than nothing.

I'm not sure "better than nothing" is good enough.

Anyway, I don't really understand what we are arguing about.

> Here's the relevant excerpt from ctags's manpage:

Thanks, but why do you think I don't have it installed?

> Ultimately, it's your choice, of course.

Volunteers are free to beat me to it, if they have an itch to scratch.

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Dmitry Gutov]

On 03/11/2016 04:59 PM, Eli Zaretskii wrote:

> I said "etags", not "emacs".

I don't think this implies any considerable amount of work in etags 
either. I could be wrong, of course.

>> And allowing the output of qualified+unqualified, in etags, doesn't seem
>> like a huge job to me.
>
> For languages where qualified tags are already created, maybe.

And it is those languages where I think the users would be served better 
by a different behavior.

> (C-like languages might be not so easy, due to the state machines they
> use.)  But are we sure all languages do?

I'm sorry, all languages do what? Use state machines, and thus are "not 
so easy"?

>> We can perfectly well choose to support this feature only for a few
>> languages. It's better than nothing.
>
> I'm not sure "better than nothing" is good enough.

I'm not buying the argument that doing the right thing is somehow 
undesirable because we can't afford to do the perfect thing right now.

Especially since the transition path from "good" to "perfect" is natural 
in this case (just add support for more languages later). This way, you 
won't have to change the semantics of -Q in future releases, or invent 
another flag that behaves similarly to -Q, "but better", and deal with 
having to document that -Q is not actually recommended for use.

> Anyway, I don't really understand what we are arguing about.

I'm arguing that -Q should output both qualified and unqualified tags, 
so that the result is actually useful.

You seem to be arguing towards -Q preserving the previous behavior of 
the parser, _in certain languages_, no matter the usefulness of the 
resulting tag files.

Apparently, to support some consumers of tag files that do it in a 
fashion we can't predict, and might somehow be inconvenienced if the 
"qualified-only" output is not one of the options. Is that correct?

>> Here's the relevant excerpt from ctags's manpage:
>
> Thanks, but why do you think I don't have it installed?

You might, or you might not. It was easier to quote directly.

Does that excerpt not make sense to you?

>> Ultimately, it's your choice, of course.
>
> Volunteers are free to beat me to it, if they have an itch to scratch.

If you've made a deliberate choice, it doesn't seem like a patch from a 
volunteer that would make a different choice is likely to be accepted.

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Eli Zaretskii]

> Cc: 22947@debbugs.gnu.org, rogers@modulargenetics.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 12 Mar 2016 03:08:13 +0200
> 
> On 03/11/2016 04:59 PM, Eli Zaretskii wrote:
> 
> > I said "etags", not "emacs".
> 
> I don't think this implies any considerable amount of work in etags 
> either. I could be wrong, of course.

I just said that etags never had these features, so we are talking
about an enhancement, not a bugfix.

> >> We can perfectly well choose to support this feature only for a few
> >> languages. It's better than nothing.
> >
> > I'm not sure "better than nothing" is good enough.
> 
> I'm not buying the argument that doing the right thing is somehow 
> undesirable because we can't afford to do the perfect thing right now.

I'm not selling it.

> > Anyway, I don't really understand what we are arguing about.
> 
> I'm arguing that -Q should output both qualified and unqualified tags, 
> so that the result is actually useful.
> 
> You seem to be arguing towards -Q preserving the previous behavior of 
> the parser, _in certain languages_, no matter the usefulness of the 
> resulting tag files.

No, I'm just saying this is a new feature whose implementation costs
are unknown to me at this point.

> >> Ultimately, it's your choice, of course.
> >
> > Volunteers are free to beat me to it, if they have an itch to scratch.
> 
> If you've made a deliberate choice, it doesn't seem like a patch from a 
> volunteer that would make a different choice is likely to be accepted.

I've made no choices, except not to work on this today.  I don't
understand why you think I'm against adding such a feature, if done
cleanly.  It's almost a reason to take offense, since I never said
anything that could be interpreted as such an intent.

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Dmitry Gutov]

All right, I'm entirely lost now.

On 03/12/2016 09:41 AM, Eli Zaretskii wrote:

>> I don't think this implies any considerable amount of work in etags
>> either. I could be wrong, of course.
>
> I just said that etags never had these features, so we are talking
> about an enhancement, not a bugfix.

"features", multiple?

> No, I'm just saying this is a new feature whose implementation costs
> are unknown to me at this point.

Just to be clear: by "new feature" here, you mean outputting both 
qualified and unqualified tags for C++, ObjC, Java, and Perl?

If so, fair enough.

>> If you've made a deliberate choice, it doesn't seem like a patch from a
>> volunteer that would make a different choice is likely to be accepted.
>
> I've made no choices, except not to work on this today.  I don't
> understand why you think I'm against adding such a feature, if done
> cleanly.  It's almost a reason to take offense, since I never said
> anything that could be interpreted as such an intent.

You've made an argument that it would somehow imply supporting qualified 
tags for all the languages, and never acknowledged the validity of my 
response. I'm not sure I understand your position anymore.

But anyway, there's a careful "if" in my previous message.

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Eli Zaretskii]

> Cc: 22947@debbugs.gnu.org, rogers@modulargenetics.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 12 Mar 2016 14:10:52 +0200
> 
> Just to be clear: by "new feature" here, you mean outputting both 
> qualified and unqualified tags for C++, ObjC, Java, and Perl?

No, all languages that have a notion of a class-qualified name.

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Dmitry Gutov]

On 03/12/2016 02:33 PM, Eli Zaretskii wrote:

>> Just to be clear: by "new feature" here, you mean outputting both
>> qualified and unqualified tags for C++, ObjC, Java, and Perl?
>
> No, all languages that have a notion of a class-qualified name.

Nobody's asking for that. We'll likely never have smart parsers like 
that for "all languages".

OK, I'm going to go file that separate feature request now.

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Eli Zaretskii]

> Cc: 22947@debbugs.gnu.org, rogers@modulargenetics.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 12 Mar 2016 14:46:50 +0200
> 
> OK, I'm going to go file that separate feature request now.

Thanks.

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Bob Rogers]

   From: Eli Zaretskii <eliz@gnu.org>
   Date: Thu, 10 Mar 2016 17:31:49 +0200

   . . .

   Bob, can you try etags from the latest emacs-25 branch?  I tried your
   recipe, and it seems to work well with "meals", but I'm not a power
   Perl user, so maybe there's some left-overs that we need to handle.

   Thanks.

Sure; I will do so when I get home this evening.  (If you could give me
a quick recipe for fetching the right branch, it might speed things up;
I'm still a Git beginner.)

   Also, FWIW, I thought I should mention that M-x find-tag works
correctly with the existing etags output . . .

					-- Bob

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Eli Zaretskii]

> From: Bob Rogers <rogers@modulargenetics.com>
> Date: Thu, 10 Mar 2016 14:07:01 -0500
> Cc: Dmitry Gutov <dgutov@yandex.ru>, 22947@debbugs.gnu.org
> 
> Sure; I will do so when I get home this evening.  (If you could give me
> a quick recipe for fetching the right branch, it might speed things up;
> I'm still a Git beginner.)

  git clone git://git.savannah.gnu.org/emacs.git

followed by

  git checkout emacs-25

>    Also, FWIW, I thought I should mention that M-x find-tag works
> correctly with the existing etags output . . .

Yes, but we are switching away of find-tag towards the xref commands.

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Bob Rogers]

   From: Eli Zaretskii <eliz@gnu.org>
   Date: Thu, 10 Mar 2016 22:32:24 +0200

   > Sure; I will do so when I get home this evening.  (If you could give me
   > a quick recipe for fetching the right branch, it might speed things up;
   > I'm still a Git beginner.)

     git clone git://git.savannah.gnu.org/emacs.git

   followed by

     git checkout emacs-25

Thank you; I wound up rebuilding the whole thing with revision 8b8a6ad.
The new etags builds the table without package qualifications, but after
"emacs -Q" and "M-x visit-tags-table", "M-." still doesn't find either
the parse_recipes or add_ingredient definitions.  FWIW, the previous
version of emacs was able to find both add_ingredient definitions, but
not parse_recipes.

   >    Also, FWIW, I thought I should mention that M-x find-tag works
   > correctly with the existing etags output . . .

   Yes, but we are switching away of find-tag towards the xref commands.

The user interface, yes, but it seemed worthy of note that the find-tag
backend works with the original etags output . . .

					-- Bob

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Eli Zaretskii]

> From: Bob Rogers <rogers@modulargenetics.com>
> Date: Fri, 11 Mar 2016 13:08:32 -0500
> Cc: dgutov@yandex.ru, 22947@debbugs.gnu.org
> 
> Thank you; I wound up rebuilding the whole thing with revision 8b8a6ad.
> The new etags builds the table without package qualifications, but after
> "emacs -Q" and "M-x visit-tags-table", "M-." still doesn't find either
> the parse_recipes or add_ingredient definitions.

Probably because you were not visiting a Perl file.  Because otherwise
it worked for me.

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Bob Rogers]

   From: Eli Zaretskii <eliz@gnu.org>
   Date: Fri, 11 Mar 2016 20:34:12 +0200

   > From: Bob Rogers <rogers@modulargenetics.com>
   > Date: Fri, 11 Mar 2016 13:08:32 -0500

   > The new etags builds the table without package qualifications, but
   > after "emacs -Q" and "M-x visit-tags-table", "M-." still doesn't
   > find either the parse_recipes or add_ingredient definitions.

   Probably because you were not visiting a Perl file.  Because otherwise
   it worked for me.

Yes, I see that now.  But shouldn't it also work from other files?  I
find it very useful to type M-. on a Perl method name that appears in
documentation or in my notes, or to find a Perl definition mentioned in
a Javascript file comment (and vice versa).

   And many Perl programs have substantial C components.  Am I to
understand that M-. between C and Elisp no longer works for Emacs?

					-- Bob

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Dmitry Gutov]

On 03/11/2016 09:05 PM, Bob Rogers wrote:

>    > The new etags builds the table without package qualifications, but
>    > after "emacs -Q" and "M-x visit-tags-table", "M-." still doesn't
>    > find either the parse_recipes or add_ingredient definitions.
>
>    Probably because you were not visiting a Perl file.  Because otherwise
>    it worked for me.

It works fine for me either way.

> Yes, I see that now.  But shouldn't it also work from other files?

One reason why it might not work, is if the same method name is not 
recognized by the other file's syntax table as the symbol at point. For 
etags, we're basically calling (thing-at-point 'symbol). You can 
evaluate this form in any context, and see if it returns the method name 
you were trying to look up.

If not, though, you can still press `C-u M-.' and type out the name of 
the method to look for (or even press M-n, see the default value 
inserted, and edit it), and press RET.

This is not too different from the find-tag workflow.

> I
> find it very useful to type M-. on a Perl method name that appears in
> documentation or in my notes, or to find a Perl definition mentioned in
> a Javascript file comment (and vice versa).

In general, it should work. Could you describe exactly what it is you 
tried (which file did you open, and where did you navigate before 
pressing `M-.'? did you press C-u?), so that we can reproduce it?

>    And many Perl programs have substantial C components.  Am I to
> understand that M-. between C and Elisp no longer works for Emacs?

You can just from C to Elisp just like before. From Elisp to C - a bit 
tricker, since emacs-lisp-mode sets up an xref backend using find-func 
by default, not etags. But you can

(add-hook 'emacs-lisp-mode-hook 'xref-etags-mode)

to make it use etags as well.

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

>>    Probably because you were not visiting a Perl file.  Because otherwise
>>    it worked for me.
>
> It works fine for me either way.

[...]

> In general, it should work. Could you describe exactly what it is you
> tried (which file did you open, and where did you navigate before
> pressing `M-.'? did you press C-u?), so that we can reproduce it?

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

The discussion then went on to whether to add new features to etags, and
Dmitry said he was going to file a separate bug report for that.

But it's unclear whether there was anything more to fix in this bug
report.  (I haven't tried reproducing the test cases.)  Bob, are you
still seeing problems in this area in recent Emacs versions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Bob Rogers]

   From: Lars Ingebrigtsen <larsi@gnus.org>
   Date: Tue, 26 Apr 2022 14:40:28 +0200

   . . .

   (I'm going through old bug reports that unfortunately weren't resolved
   at the time.)

   The discussion then went on to whether to add new features to etags, and
   Dmitry said he was going to file a separate bug report for that.

   But it's unclear whether there was anything more to fix in this bug
   report.  (I haven't tried reproducing the test cases.)  Bob, are you
   still seeing problems in this area in recent Emacs versions?

No; in fact, I had completely forgotten about this.  I've had no further
issues of this nature with M-. -- in Perl or elsewhere.

					-- Bob Rogers
					   http://www.rgrjr.com/

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Lars Ingebrigtsen]

Bob Rogers <rogers@modulargenetics.com> writes:

> No; in fact, I had completely forgotten about this.  I've had no further
> issues of this nature with M-. -- in Perl or elsewhere.

Thanks; I'm closing this bug report, then.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags

[Dmitry Gutov]

On 03/10/2016 09:07 PM, Bob Rogers wrote:

>    Also, FWIW, I thought I should mention that M-x find-tag works
> correctly with the existing etags output . . .

By default, find-tag-tag-order is set to a very lax list (in 
etags-recognize-tags-table). In comparison, 
etags-xref-find-definitions-tag-order is relatively strict.

We've decided to prefer the latter approach, because with lax matching 
come more false positives. But users can modify the latter variable to 
their liking as well.