GNU bug report logs -
#22947
25.0.92; xref-find-definitions fails for Perl & etags
Previous Next
Reported by: Bob Rogers <rogers <at> modulargenetics.com>
Date: Tue, 8 Mar 2016 19:14:02 UTC
Severity: normal
Tags: moreinfo
Found in version 25.0.92
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 22947 in the body.
You can then email your comments to 22947 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Tue, 08 Mar 2016 19:14:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Bob Rogers <rogers <at> modulargenetics.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 08 Mar 2016 19:14:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Wed, 09 Mar 2016 01:53:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 22947 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Wed, 09 Mar 2016 02:44:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 22947 <at> debbugs.gnu.org (full text, mbox):
From: Dmitry Gutov <dgutov <at> 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 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Thu, 10 Mar 2016 13:21:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 22947 <at> debbugs.gnu.org (full text, mbox):
> From: Bob Rogers <rogers <at> modulargenetics.com>
> Date: Tue, 8 Mar 2016 21:43:48 -0500
> Cc: 22947 <at> 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 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Thu, 10 Mar 2016 13:38:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 22947 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Thu, 10 Mar 2016 14:17:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 22947 <at> debbugs.gnu.org (full text, mbox):
> Cc: 22947 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Thu, 10 Mar 2016 14:35:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 22947 <at> debbugs.gnu.org (full text, mbox):
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).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Thu, 10 Mar 2016 15:32:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 22947 <at> debbugs.gnu.org (full text, mbox):
> Cc: 22947 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Thu, 10 Mar 2016 15:51:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 22947 <at> debbugs.gnu.org (full text, mbox):
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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Thu, 10 Mar 2016 16:23:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 22947 <at> debbugs.gnu.org (full text, mbox):
> Cc: 22947 <at> debbugs.gnu.org, rogers <at> modulargenetics.com
> From: Dmitry Gutov <dgutov <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Thu, 10 Mar 2016 19:08:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 22947 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Thu, 10 Mar 2016 20:33:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 22947 <at> debbugs.gnu.org (full text, mbox):
> From: Bob Rogers <rogers <at> modulargenetics.com>
> Date: Thu, 10 Mar 2016 14:07:01 -0500
> Cc: Dmitry Gutov <dgutov <at> yandex.ru>, 22947 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Fri, 11 Mar 2016 01:29:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 22947 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Fri, 11 Mar 2016 01:46:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 22947 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Fri, 11 Mar 2016 08:05:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 22947 <at> debbugs.gnu.org (full text, mbox):
> Cc: 22947 <at> debbugs.gnu.org, rogers <at> modulargenetics.com
> From: Dmitry Gutov <dgutov <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Fri, 11 Mar 2016 12:47:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 22947 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Fri, 11 Mar 2016 15:00:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 22947 <at> debbugs.gnu.org (full text, mbox):
> Cc: 22947 <at> debbugs.gnu.org, rogers <at> modulargenetics.com
> From: Dmitry Gutov <dgutov <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Fri, 11 Mar 2016 18:09:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 22947 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Fri, 11 Mar 2016 18:35:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 22947 <at> debbugs.gnu.org (full text, mbox):
> From: Bob Rogers <rogers <at> modulargenetics.com>
> Date: Fri, 11 Mar 2016 13:08:32 -0500
> Cc: dgutov <at> yandex.ru, 22947 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Fri, 11 Mar 2016 19:06:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 22947 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org>
Date: Fri, 11 Mar 2016 20:34:12 +0200
> From: Bob Rogers <rogers <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Sat, 12 Mar 2016 00:51:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 22947 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Sat, 12 Mar 2016 01:09:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 22947 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Sat, 12 Mar 2016 07:43:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 22947 <at> debbugs.gnu.org (full text, mbox):
> Cc: 22947 <at> debbugs.gnu.org, rogers <at> modulargenetics.com
> From: Dmitry Gutov <dgutov <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Sat, 12 Mar 2016 12:12:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 22947 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Sat, 12 Mar 2016 12:35:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 22947 <at> debbugs.gnu.org (full text, mbox):
> Cc: 22947 <at> debbugs.gnu.org, rogers <at> modulargenetics.com
> From: Dmitry Gutov <dgutov <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Sat, 12 Mar 2016 12:48:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 22947 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Sat, 12 Mar 2016 16:11:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 22947 <at> debbugs.gnu.org (full text, mbox):
> Cc: 22947 <at> debbugs.gnu.org, rogers <at> modulargenetics.com
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Sat, 12 Mar 2016 14:46:50 +0200
>
> OK, I'm going to go file that separate feature request now.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Tue, 26 Apr 2022 12:41:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 22947 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> 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
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Tue, 26 Apr 2022 12:41:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Tue, 26 Apr 2022 17:01:01 GMT)
Full text and
rfc822 format available.
Message #91 received at 22947 <at> debbugs.gnu.org (full text, mbox):
From: Lars Ingebrigtsen <larsi <at> 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/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#22947; Package
emacs.
(Wed, 27 Apr 2022 12:15:02 GMT)
Full text and
rfc822 format available.
Message #94 received at 22947 <at> debbugs.gnu.org (full text, mbox):
Bob Rogers <rogers <at> 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 closed, send any further explanations to
22947 <at> debbugs.gnu.org and Bob Rogers <rogers <at> modulargenetics.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Wed, 27 Apr 2022 12:15:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 26 May 2022 11:24:10 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 36 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.