From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#20629: 25.0.50; Regression: TAGS broken, can't find anything in C++ files. Date: Fri, 29 May 2015 17:05:53 +0300 Message-ID: <55687241.5030200@yandex.ru> References: <555EC552.5010600@swipnet.se> <55606A8F.1020109@swipnet.se> <55606CC7.3010401@yandex.ru> <55606F70.10605@swipnet.se> <83twv31jzg.fsf@gnu.org> <83pp5r1hdx.fsf@gnu.org> <83mw0v1e5n.fsf@gnu.org> <83lhgczo16.fsf@gnu.org> <55639175.9090005@yandex.ru> <83fv6kysjf.fsf@gnu.org> <556447EF.3050103@yandex.ru> <83bnh7z8c5.fsf@gnu.org> <5564C2C7.5050909@yandex.ru> <837frvywfn.fsf@gnu.org> <55650812.60909@yandex.ru> <831ti2yu1a.fsf@gnu.org> <5565E28A.5040507@yandex.ru> <83wpzuxbtd.fsf@gnu.org> <5565E8AB.5020107@yandex.ru> <83r3q2xa3q.fsf@gnu.org> <5566583F.7020503@yandex.ru> <83h9qxxvo4.fsf@gnu.org> <5566EC49.8010907@yandex.ru> <837frsycly.fsf@gnu.org> <5567351E.7020006@yandex.ru> <83zj4owthp.fsf@gnu.org> <5567AE52.1000600@yandex.ru> <83fv6fx0nk.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1432908489 24217 80.91.229.3 (29 May 2015 14:08:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 May 2015 14:08:09 +0000 (UTC) Cc: 20629@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 29 16:07:58 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YyKwT-0002s8-7u for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 May 2015 16:07:21 +0200 Original-Received: from localhost ([::1]:36143 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YyKwN-0001ox-MS for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 May 2015 10:07:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35028) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YyKwH-0001op-9M for bug-gnu-emacs@gnu.org; Fri, 29 May 2015 10:07:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YyKwB-0002Jn-Gg for bug-gnu-emacs@gnu.org; Fri, 29 May 2015 10:07:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50772) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YyKwB-0002Jj-BR for bug-gnu-emacs@gnu.org; Fri, 29 May 2015 10:07:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YyKwA-0007cE-TI for bug-gnu-emacs@gnu.org; Fri, 29 May 2015 10:07:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 29 May 2015 14:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20629 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20629-submit@debbugs.gnu.org id=B20629.143290836429204 (code B ref 20629); Fri, 29 May 2015 14:07:02 +0000 Original-Received: (at 20629) by debbugs.gnu.org; 29 May 2015 14:06:04 +0000 Original-Received: from localhost ([127.0.0.1]:60747 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YyKvD-0007ax-3j for submit@debbugs.gnu.org; Fri, 29 May 2015 10:06:03 -0400 Original-Received: from mail-wi0-f171.google.com ([209.85.212.171]:35389) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YyKvA-0007aU-W2 for 20629@debbugs.gnu.org; Fri, 29 May 2015 10:06:02 -0400 Original-Received: by wicmx19 with SMTP id mx19so18831818wic.0 for <20629@debbugs.gnu.org>; Fri, 29 May 2015 07:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=kp72G1/f9hrWLQQ8rOVpNWMSgmO5FuHwk8pcSuiQsDo=; b=ZiPnUcT0R66KR30X4hCePsm0anG3Ha3cQH/oBfY/DywNuCetthwWgJdwUMbANhg1hB u2jr4Y8KF9BWSl4V8Dx7r0n+WAXZox1K+36j3YQllK+qBscleZsnKyfe5BmwRWWrmqZb ebm4ml6enjrTwxRXdlGU28Bgv6ONXxyT7zWUUFdVtmrdbP3XPeI0vVf9zxjlXCb28ntA bXSbgoCkxZRaSZOt/78ypmftS9/KneJCnAfzaxR9tB4XU53ohVyXvLN7cTm7jFmhniYX poQ7n74dZOxI1hFauQg7hBw6LsnABdkTUoXht/7vZwAuu01T4XIhDllR69TpX/+9F75i bLEA== X-Received: by 10.194.172.130 with SMTP id bc2mr15845380wjc.85.1432908355242; Fri, 29 May 2015 07:05:55 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id fb3sm3270524wib.21.2015.05.29.07.05.54 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 May 2015 07:05:55 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: <83fv6fx0nk.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:103310 Archived-At: On 05/29/2015 11:12 AM, Eli Zaretskii wrote: >>> But having just qualified tags is bad for accuracy, right? >> >> Maybe. Depends on things we would add to the Lisp code. > > Can you elaborate? Is there a way to get the same accuracy and > completion without having both qualified and unqualified tags? There'll have to be some compromise, but not necessarily in accuracy. The present default behavior is accurate enough, and by that I mean the user can navigate to a method call, press M-., and see all definitions of the methods with that name, without extra junk. What we don't have by default, is completion, and navigation to, qualified method names. That's by itself, is a relatively advances feature (the user needs to know to press C-u and then either press TAB and look for qualified names, or type one out). That can be mitigated by parsing out implicit tag names out of patterns, however they also don't always contain qualified names (which was my misunderstanding: they do in the toy example provided by Jan). So, having qualified names in tag completion reliably is out of the question, unless etags uses them in tag names. And then we'd have to solve the question of how to get the unqualified names in both completion and navigation (continued below (*)). > Yes, but I think if we change etags to create duplicate tags, we > should have this feature opt-out, unlike Exuberant, otherwise TAGS > created by default will be deficient with xref. Do you agree? I'd say no. First, there's value is simply being compatible. Second, as the ctags man page warns, including both qualified and unqualified names in separate entries, "could potentially more than double the size of the tag file". Which increases the time it takes to load one, and might (if we make more progress on Stefan's suggestion not to pre-build tags completion table) also make completion slower, in projects of certain size. (*) However, I don't really understand this choice: """ 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". """ If we posit that in each interesting language a qualified tag is of the form CONTEXT-CHAR-NAME, standardizing on CHAR would allow us to extract both qualified and unqualified tag names from a single entry, at a small cost in readability for users where the language traditionally uses a different separator than the one picked by etags. For better uniqueness, I'd choose two of them: # before instance methods, and . before class (or static) methods. This notation is fairly popular and is used in Javadocs, as well as in different comment formats Ruby uses.