From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii 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 21:28:39 +0300 Message-ID: <83617bw84o.fsf@gnu.org> 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> <55687241.5030200@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1432924162 9030 80.91.229.3 (29 May 2015 18:29:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 May 2015 18:29:22 +0000 (UTC) Cc: 20629@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 29 20:29:12 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 1YyP1r-0001D8-7u for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 May 2015 20:29:11 +0200 Original-Received: from localhost ([::1]:37349 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YyP1q-0008Kt-9N for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 May 2015 14:29:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51339) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YyP1m-0008Kk-Vh for bug-gnu-emacs@gnu.org; Fri, 29 May 2015 14:29:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YyP1i-0006pP-UI for bug-gnu-emacs@gnu.org; Fri, 29 May 2015 14:29:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50871) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YyP1i-0006pL-QZ for bug-gnu-emacs@gnu.org; Fri, 29 May 2015 14:29:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YyP1i-00075G-77 for bug-gnu-emacs@gnu.org; Fri, 29 May 2015 14:29:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 29 May 2015 18:29: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.143292413427215 (code B ref 20629); Fri, 29 May 2015 18:29:02 +0000 Original-Received: (at 20629) by debbugs.gnu.org; 29 May 2015 18:28:54 +0000 Original-Received: from localhost ([127.0.0.1]:60846 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YyP1Z-00074s-Hc for submit@debbugs.gnu.org; Fri, 29 May 2015 14:28:54 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:38785) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YyP1V-00074d-Qn for 20629@debbugs.gnu.org; Fri, 29 May 2015 14:28:51 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NP400200IVCMU00@a-mtaout22.012.net.il> for 20629@debbugs.gnu.org; Fri, 29 May 2015 21:28:43 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NP4002WKJBUNI00@a-mtaout22.012.net.il>; Fri, 29 May 2015 21:28:43 +0300 (IDT) In-reply-to: <55687241.5030200@yandex.ru> X-012-Sender: halo1@inter.net.il 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:103324 Archived-At: > Cc: 20629@debbugs.gnu.org > From: Dmitry Gutov > Date: Fri, 29 May 2015 17:05:53 +0300 > > 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). At least in C++, class members can be qualified explicitly in the source (which was what Jan's example did), or they can be qualified implicitly, by including them inside braced constructs, for example. For the latter, etags (now only under -Q) adds the qualifications when it generates the tags. The code I added _removes_ the explicit qualifications, and doesn't add the ones for implicitly qualified members. > So, having qualified names in tag completion reliably is out of the > question, unless etags uses them in tag names. Exactly. > > 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. Compatibility aside, I think what most users will want should be the default. What Exuberant ctags does now might not yet reflect the changes in Emacs, from etags.el's UI to xfer. Once they learn about that, they might turn that flag on by default as well. > 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". Who cares? Disk space is no longer at premium. > 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. For moderate-size projects, the obarray-based completion is instantaneous, so I'm not afraid of this. > """ > 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. I don't think we can safely do that, since different characters can appear in identifiers of different languages. By using the qualifier string that is natural for the language, we make sure we never get conflicts with the identifiers themselves. Also, these qualified tags are for human consumption, which is another argument on favor of language-specific syntax. > 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. Which means C++ programmers will probably be confused by them.