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 22:42:26 +0300 Message-ID: <556A12A2.8030002@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> <5569BE61.7010200@yandex.ru> <83a8wmuog6.fsf@gnu.org> <5569D136.90802@yandex.ru> <837frquilf.fsf@gnu.org> <5569F77D.5070903@yandex.ru> <831thxvr7d.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 1433015001 26366 80.91.229.3 (30 May 2015 19:43:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 May 2015 19:43:21 +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 21:43:10 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 1Yymf0-0000Fw-DC for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 May 2015 21:43:10 +0200 Original-Received: from localhost ([::1]:40352 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yymez-0004ib-PS for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 May 2015 15:43:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38674) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yymew-0004iU-8a for bug-gnu-emacs@gnu.org; Sat, 30 May 2015 15:43:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yymet-00043U-1D for bug-gnu-emacs@gnu.org; Sat, 30 May 2015 15:43:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52023) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yymes-00043Q-To for bug-gnu-emacs@gnu.org; Sat, 30 May 2015 15:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Yymes-0005Wd-GR for bug-gnu-emacs@gnu.org; Sat, 30 May 2015 15:43:02 -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 19:43: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.143301495921209 (code B ref 20629); Sat, 30 May 2015 19:43:02 +0000 Original-Received: (at 20629) by debbugs.gnu.org; 30 May 2015 19:42:39 +0000 Original-Received: from localhost ([127.0.0.1]:33765 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YymeT-0005Vz-Kl for submit@debbugs.gnu.org; Sat, 30 May 2015 15:42:38 -0400 Original-Received: from mail-wg0-f52.google.com ([74.125.82.52]:34333) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YymeR-0005Vj-Mj for 20629@debbugs.gnu.org; Sat, 30 May 2015 15:42:36 -0400 Original-Received: by wgv5 with SMTP id 5so86040500wgv.1 for <20629@debbugs.gnu.org>; Sat, 30 May 2015 12:42:30 -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=Ph9to2RL691fsKZFc6X/K8g7SIATuKkwMKtWJQk4/H4=; b=xyDrVyib6MlxBuTntb2rmcBbuclY+JOm9HwuhQjsGCsBKfbNm4icwM9IsqGZY9k6jW bbDeqmpSQ5J026K6ZG+IToKD28hgEjythiu4OObVMFzYPd4M65uBoLKIcgK0o54nFLKv 7Bwkj/cEn6gLf8zQaH7pN1GY1HLyH2QfygZYxipuQLYIRGpAECFYyWvAVy+gTt8CUwtr lM7YUQP0gqs+/WGSHjcRSpnhJLL1O7z4i/Qd74nkDPK9XjqVcMXf2YRUxK2aprJpCKmN oc02lxLTSuni29PgQyBN4A0rgNDmTuqpqqLUw6kWcp0UigtSocgh6mSDmHIxQ4TRijic s4Pw== X-Received: by 10.194.157.194 with SMTP id wo2mr26987290wjb.103.1433014950125; Sat, 30 May 2015 12:42:30 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id ju2sm8815862wid.12.2015.05.30.12.42.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 May 2015 12:42:29 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: <831thxvr7d.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:103389 Archived-At: On 05/30/2015 09:46 PM, Eli Zaretskii wrote: > You said "based on correctness". If the 2-entry alternative > facilitates more correct operation, that's the alternative we should > choose, no? It adds a capability (to perform the search based on fully qualified name), rather than improving correctness. But again, it's a separate question. You don't have to persuade me on that choice, but I'm inclined toward compatibility with Ex-Ctags. >>> Then how will you find or complete on "foo" when the explicit tag is >>> "XX::foo"? >> >> I'd like to repeat that the current choice is between having only >> unqualified method names in explicit tags, or having both qualified and >> unqualified method names (2 entries per line). >> >> Having only a qualified entry is not a situation we're going to handle. > > You elide too much of the previous context, and I cannot afford > reading 2 or 3 previous messages to restore that (and please don't > rely on my memory too much). So I no longer understand what we are > talking about here. Sorry, I don't know where to start clarifying. In the previous message I've explained why your question, quoted above, doesn't make sense: the TAGS file must have another entry, for the same line, where the explicit tag is "foo". That one will be matched, not "XX::foo". This discussion has grown quite long already. Francesco seems to agree with my conclusions, so I'm going to make the change. > Including the pattern (what you call "the implicit tag") in the > completion table could serve as context for disambiguating otherwise > similar tag names. But if you think it's unneeded, I'm not going to > argue. Here you're using a term that's not part of the usual completion table terminology. Context? Apparently you mean annotation, which would be possible (*), but using the pattern as annotation for the current entry's tag name is not at all the same as including the implicit tag name (derived from the pattern) in the completion table. Which means adding it as a separate element. For simplicity, think of this completion table as a list, especially now it's implemented as such. (*) But not necessarily advisable, and would bring its own challenge WRT implementation.