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 03:45:39 +0200	[thread overview]
Message-ID: <2c9b9fe9-4df0-1ba2-123d-ab4743bf49ca@yandex.ru> (raw)
In-Reply-To: <83io0ul2vb.fsf@gnu.org>

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.





  reply	other threads:[~2016-03-11  1:45 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 [this message]
2016-03-11  8:04                 ` Eli Zaretskii
2016-03-11 12:46                   ` Dmitry Gutov
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=2c9b9fe9-4df0-1ba2-123d-ab4743bf49ca@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).