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: Sat, 30 May 2015 19:37:48 +0300 Message-ID: <837frquilf.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> <83mw0muv5m.fsf@gnu.org> <5569AD7F.2000402@yandex.ru> <83iobautar.fsf@gnu.org> <5569BE61.7010200@yandex.ru> <83a8wmuog6.fsf@gnu.org> <5569D136.90802@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1433003961 20305 80.91.229.3 (30 May 2015 16:39:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 May 2015 16:39:21 +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 Sat May 30 18:39:11 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 1Yyjmw-0000B6-Oz for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 May 2015 18:39:10 +0200 Original-Received: from localhost ([::1]:39982 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yyjmw-00044M-5t for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 May 2015 12:39:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42012) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yyjms-00044H-Fc for bug-gnu-emacs@gnu.org; Sat, 30 May 2015 12:39:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yyjmp-0006Jy-7m for bug-gnu-emacs@gnu.org; Sat, 30 May 2015 12:39:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51926) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yyjmp-0006Jk-3X for bug-gnu-emacs@gnu.org; Sat, 30 May 2015 12:39:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Yyjmo-00081W-67 for bug-gnu-emacs@gnu.org; Sat, 30 May 2015 12:39: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: Sat, 30 May 2015 16:39: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.143300391730809 (code B ref 20629); Sat, 30 May 2015 16:39:02 +0000 Original-Received: (at 20629) by debbugs.gnu.org; 30 May 2015 16:38:37 +0000 Original-Received: from localhost ([127.0.0.1]:33668 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YyjmO-00080r-2Y for submit@debbugs.gnu.org; Sat, 30 May 2015 12:38:36 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:57806) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YyjmK-00080b-RN for 20629@debbugs.gnu.org; Sat, 30 May 2015 12:38:34 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NP600C008I9Y100@mtaout25.012.net.il> for 20629@debbugs.gnu.org; Sat, 30 May 2015 19:33:41 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NP6003T28O5CF80@mtaout25.012.net.il>; Sat, 30 May 2015 19:33:41 +0300 (IDT) In-reply-to: <5569D136.90802@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:103373 Archived-At: > Cc: 20629@debbugs.gnu.org > From: Dmitry Gutov > Date: Sat, 30 May 2015 18:03:18 +0300 > > >> - Like you mentioned, it's not always that qualified name occurs in the > >> pattern. Sometimes it's creates using curly braces and such, and thus > >> can only occur in an explicit tag name (which the discussed patch won't > >> account for). Thus, some qualified names would be present in > >> completions, and some won't. This is bad. > > > > Do you have an actual example? AFAIU, this shouldn't happen: etags > > only decides that an explicit tag name is unneeded when it can be > > deduced from the pattern. So if the explicit tag is not in TAGS, it > > means etags.el can find it in the pattern. (Qualified tag names that > > are constructed by etags are never in the pattern, so they will always > > get explicit tag names.) > > I believe that the current choice is between "etags produces unqualified > tags" and "etags produces both qualified and unqualified tags for lines > where the distinction appies" (2 entries per line). Yes. > In the latter case the patch above is extraneous. So above I'm > describing the situation where etags produces unqualified tags (which it > currently does, by default). OK. > > Yes, but I'd like to make a decision before making the change for > > placing 2 entries, so that the number of backward-incompatible changes > > could be minimized. > > I think that would be a mistake. Rather, we should make the choice based > on correctness. Won't TAGS file with 2 entries for such symbols facilitate more correct operation, both from xref-find-definitions and completion? > >> It's harder to present a realistic case of a user looking for one thing > >> and getting another, but the point is, is the Etags parser decided that > >> the implicit tag doesn't match the explicit tag, we should ignore the > >> former (because we don't really know the way they mismatch). > > > > I think we already do. > > Currently, we don't put the implicit tag into the completion table if > the explicit tag is present. > > But we do match implicit tags during navigation, even when an explicit > tag is there. > > The aforementioned patch would include the implicit tag in the > completion table anyway. I'm now saying we don't want that, and we also > don't want navigation to match implicit tags in the entries that contain > an explicit tag as well. Then how will you find or complete on "foo" when the explicit tag is "XX::foo"?