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: Sat, 30 May 2015 16:42:57 +0300 Message-ID: <5569BE61.7010200@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> <83mw0muv5m.fsf@gnu.org> <5569AD7F.2000402@yandex.ru> <83iobautar.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 1432993464 22673 80.91.229.3 (30 May 2015 13:44:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 May 2015 13:44:24 +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 Sat May 30 15:44:13 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 1Yyh3c-0005xb-5k for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 May 2015 15:44:12 +0200 Original-Received: from localhost ([::1]:39520 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yyh3b-0004hz-LJ for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 May 2015 09:44:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45948) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yyh3X-0004hu-5u for bug-gnu-emacs@gnu.org; Sat, 30 May 2015 09:44:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yyh3U-0003Uh-0y for bug-gnu-emacs@gnu.org; Sat, 30 May 2015 09:44:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51242) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yyh3T-0003US-Ti for bug-gnu-emacs@gnu.org; Sat, 30 May 2015 09:44:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Yyh3T-0003oY-1c for bug-gnu-emacs@gnu.org; Sat, 30 May 2015 09:44: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: Sat, 30 May 2015 13:44: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.143299339014591 (code B ref 20629); Sat, 30 May 2015 13:44:02 +0000 Original-Received: (at 20629) by debbugs.gnu.org; 30 May 2015 13:43:10 +0000 Original-Received: from localhost ([127.0.0.1]:32984 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yyh2b-0003nH-76 for submit@debbugs.gnu.org; Sat, 30 May 2015 09:43:09 -0400 Original-Received: from mail-wg0-f53.google.com ([74.125.82.53]:35403) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yyh2Y-0003mk-Pw for 20629@debbugs.gnu.org; Sat, 30 May 2015 09:43:07 -0400 Original-Received: by wgme6 with SMTP id e6so82291291wgm.2 for <20629@debbugs.gnu.org>; Sat, 30 May 2015 06:43:01 -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=NvrJ2ls3cnY1BE8XbYxcWL6Ix7359HkhRbksFV8mR90=; b=KolUNpbGJvuZjJT8Hz0sJ5LO63m2MsEjCmVSFTCInpGalsIQrvixexjPfLDS6ZnS2m EkaGkfjxQjGUj2Pga24CJdsvsVMh+YDgjjzGo2Xm9sS2MT3C8gSbGjclf+CYOCNpvr5R dsKmaVKKPTIg6VPfCp8ug9RO1v9zkP9BPmRRfNEOf3O064VkTMuyDmsLBIUv9GYSsJwL 4o8iXhbstYXOHrrM6Rs7p/07vdUZH4vSRtKc/WUJ3omeIpOFhIc4WwUXDkSzjmU/SUa3 +w09gp9Iz8NQ3IETEYPSgzOjQ/r4qSX5gQPElONNQDd66rt2MOmMVY2+WJRGx7ePnbvq qggw== X-Received: by 10.180.77.8 with SMTP id o8mr5006080wiw.74.1432993380963; Sat, 30 May 2015 06:43:00 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id b10sm7659513wic.1.2015.05.30.06.43.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 May 2015 06:43:00 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: <83iobautar.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:103363 Archived-At: On 05/30/2015 03:46 PM, Eli Zaretskii wrote: > It seemed to show both qualified and unqualified names, AFAICS. I'd rather the comparison was made when TAGS is using 2-lines-per-item. Having two different ways to obtain the qualified names doesn't sounds good to me, and using implicit tag names is faulty: - 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. - See below (*). >> Err, these changes are orthogonal, if not to say complete opposites. If >> there are two lines in TAGS for each item, no change to >> etags-tags-completion-table should be necessary. > > The question still stands. It's only the question of the default behavior that's still undecided. The user will have a way to see qualified names either way. > But tag-implicit-name-match-p is called after tag-exact-match-p, so > the latter cannot be the fallback for the former. I'm not sure what you mean. Why fallback? (*) Consider this: if the explicit tag name is present, then the tag name we can guess from the pattern implicitly is _incorrect_, so it's wrong to match it. For instance, visit lisp/TAGS and try to navigate to "'edit-abbrevs-map" (yes, including a quote). There will be a match, but it was in fact a faulty search: an Elisp identifier can't include a quote. 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).