From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Francesco =?UTF-8?Q?Potort=C3=AC?= 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 21:35:14 +0200 Message-ID: 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> <5569FDCA.4030801@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1433014582 20262 80.91.229.3 (30 May 2015 19:36:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 May 2015 19:36: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 Sat May 30 21:36: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 1YymYF-0004EK-8i for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 May 2015 21:36:11 +0200 Original-Received: from localhost ([::1]:40337 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YymYE-0001uu-Cx for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 May 2015 15:36:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37368) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YymYA-0001up-6n for bug-gnu-emacs@gnu.org; Sat, 30 May 2015 15:36:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YymY6-0001wD-Th for bug-gnu-emacs@gnu.org; Sat, 30 May 2015 15:36:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52019) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YymY6-0001w9-QF for bug-gnu-emacs@gnu.org; Sat, 30 May 2015 15:36:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YymY6-0005LV-K9 for bug-gnu-emacs@gnu.org; Sat, 30 May 2015 15:36:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Francesco =?UTF-8?Q?Potort=C3=AC?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 May 2015 19:36: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.143301452120496 (code B ref 20629); Sat, 30 May 2015 19:36:02 +0000 Original-Received: (at 20629) by debbugs.gnu.org; 30 May 2015 19:35:21 +0000 Original-Received: from localhost ([127.0.0.1]:33761 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YymXQ-0005KV-Ks for submit@debbugs.gnu.org; Sat, 30 May 2015 15:35:21 -0400 Original-Received: from blade3.isti.cnr.it ([194.119.192.19]:29092) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YymXN-0005KJ-5Z for 20629@debbugs.gnu.org; Sat, 30 May 2015 15:35:18 -0400 Original-Received: from tucano.isti.cnr.it ([146.48.81.102]) by mx.isti.cnr.it (PMDF V6.5-x6 #32097) with ESMTPSA id <01PMLM8P3IW6MEP5VN@mx.isti.cnr.it> for 20629@debbugs.gnu.org; Sat, 30 May 2015 21:35:15 +0200 (MEST) Original-Received: from pot by tucano.isti.cnr.it with local (Exim 4.85) (envelope-from ) id 1YymXK-0003o3-R0; Sat, 30 May 2015 21:35:14 +0200 In-reply-to: <5569FDCA.4030801@yandex.ru> X-INSM-ip-source: 146.48.81.102 Auth Done X-fingerprint: 4B02 6187 5C03 D6B1 2E31 7666 09DF 2DC9 BE21 6115 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:103388 Archived-At: >> Sorry if I don't closely follow the discussion (I do not know all the >> internals of etags.el), and consequently sorry if I am misanderstanding >> anything. In that case, please discard my observations below. > >I don't think I'm misunderstanding: it's mainly a problem of terminology. I was fearing *I* was the one who misunderstands :) Anyway, probably it's also a terminology problem, and that's my fault too. You are right that what I called "implicit / explicit tag" is in fact an "implicit / explicit tag name". Sorry about that, it has been a long time since I worked on that. In the etc/ETAGS.EBNF file you can read the complete description that I made at that time. Here it is: ======================= 2) discussion of tag names ======================= - WHAT ARE TAG NAMES Tag lines in a tags file are usually made from the above defined pattern and by an optional tag name. The pattern is a string that is searched in the source file to find the tagged line. - WHY TAG NAMES ARE GOOD When a user looks for a tag, Emacs first compares the tag with the tag names contained in the tags file. If no match is found, Emacs compares the tag with the patterns. The tag name is then the preferred way to look for tags in the tags file, because when the tag name is present Emacs can find a tag faster and more accurately. These tag names are part of tag lines in the tags file, so we call them "explicit". - WHY IMPLICIT TAG NAMES ARE EVEN BETTER When a tag line has no name, but a name can be deduced from the pattern, we say that the tag line has an implicit tag name. Often tag names are redundant; this happens when the name of a tag is an easily guessable substring of the tag pattern. We define a set of rules to decide whether it is possible to deduce the tag name from the pattern, and make an unnamed tag in those cases. The name deduced from the pattern of an unnamed tag is the implicit name of that tag. When the user looks for a tag, and Emacs finds no explicit tag names that match it, Emacs then looks for an tag whose implicit tag name matches the request. etags.c uses implicit tag names when possible, in order to reduce the size of the tags file. An implicit tag name is deduced from the pattern by discarding the last character if it is one of ` \f\t\n\r()=,;', then taking all the rightmost consecutive characters in the pattern which are not one of those. ===================== end of discussion of tag names ===================== >> Implicit tags are semantically the same as explicit tags. Whether a tag >> is implicit or explicit, it's only a matter of efficiency in building >> the TAGS file. For a given TAGS file entry, there is either no tag, or >> an implicit tag, or an explicit tag. > >Maybe we should say that there's always a "tag name", for a given entry. >And we can determine it by looking at the tag name field, or, in the >absence of it, implicitly determine from the pattern. Right. But thereés more. We can have either: 1) explicit tag name 2) implicit tag name (unnamed tag whose name can be deduced from pattern) 3) no tag name (unnamed tag) In some languages, like C++ and derived, most tags are named. In others, most are unnamed, usually in the simplest languages. >It's easier to call the value of the tag name field an "explicit tag", >and the value that we can derive from the pattern an "implicit tag". And >if the explicit tag is present, naturally they'll be different. Well, no. Or at least, it's not how they were intended. The parser finds a tag, then it decides whether it should be named or not and in the latter case, depending on the tag and the language, what is the appropriate tag name. If the tag should have no name, an unnamed tag is created. If the tag should be named, and if the name can be deduced from the pattern, then it creates no explicit name (thus creating an unnamed tag with an implicit tag name), else it creates a tag with an explicit name. The idea is that when you look for a tag, you first look for the (explicit) names in the tag, which are contained in the relevant field. If you find one, it's done. If it is not, you can try and see if the tag you are looking for matches an implicit name. If you find one, it's done. If you don't, then you should try and match the unnamed patterns (in practice, I think that etags.el tries and matches all the patterns). So there is no such thing as an explicit name plus an implicit name for the same tag. Or at least, it was never intended to work like that. >> The latter two cases should be >> treated exactly alike by whichever program is reading the TAGS file. >> Nor is it possible that for a given entry its implicit tag does not >> match its explicit tag, because either the former or the latter are >> present, not both. > >This confirms that we should always disregard implicit tag when the >explicit tag is present. I suppose you can view it like this so. In my language, I would say that when an explicit name is present, we have found a name. That's all, no thing like an "implicit tag name" is there to be disregarded.