unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 22947@debbugs.gnu.org, rogers@modulargenetics.com
Subject: bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags
Date: Fri, 11 Mar 2016 14:46:25 +0200	[thread overview]
Message-ID: <c60804f4-1b9b-4661-b4b9-e1c567587fb0@yandex.ru> (raw)
In-Reply-To: <83ziu5jv92.fsf@gnu.org>

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.





  reply	other threads:[~2016-03-11 12:46 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-08 18:27 bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags Bob Rogers
2016-03-09  1:52 ` Dmitry Gutov
2016-03-09  2:43   ` Bob Rogers
2016-03-10 13:20     ` Eli Zaretskii
2016-03-10 13:36       ` Dmitry Gutov
2016-03-10 14:16         ` Eli Zaretskii
2016-03-10 14:34           ` Dmitry Gutov
2016-03-10 15:31         ` Eli Zaretskii
2016-03-10 15:50           ` Dmitry Gutov
2016-03-10 16:22             ` Eli Zaretskii
2016-03-11  1:45               ` Dmitry Gutov
2016-03-11  8:04                 ` Eli Zaretskii
2016-03-11 12:46                   ` Dmitry Gutov [this message]
2016-03-11 14:59                     ` Eli Zaretskii
2016-03-12  1:08                       ` Dmitry Gutov
2016-03-12  7:41                         ` Eli Zaretskii
2016-03-12 12:10                           ` Dmitry Gutov
2016-03-12 12:33                             ` Eli Zaretskii
2016-03-12 12:46                               ` Dmitry Gutov
2016-03-12 16:09                                 ` Eli Zaretskii
2016-03-10 19:07           ` Bob Rogers
2016-03-10 20:32             ` Eli Zaretskii
2016-03-11 18:08               ` Bob Rogers
2016-03-11 18:34                 ` Eli Zaretskii
2016-03-11 19:05                   ` Bob Rogers
2016-03-12  0:50                     ` Dmitry Gutov
2022-04-26 12:40                       ` Lars Ingebrigtsen
2022-04-26 17:00                         ` Bob Rogers
2022-04-27 12:14                           ` Lars Ingebrigtsen
2016-03-11  1:28             ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c60804f4-1b9b-4661-b4b9-e1c567587fb0@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=22947@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=rogers@modulargenetics.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).