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#21934: 24.5; find-tag: reading TAGS file incorrectly Date: Sun, 22 Nov 2015 03:17:09 +0200 Message-ID: <56511795.2050207@yandex.ru> References: <87ziyd20cb.fsf@winky.hogwarts> <564AA697.9000203@yandex.ru> <83egfj4i2b.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1448155110 18082 80.91.229.3 (22 Nov 2015 01:18:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Nov 2015 01:18:30 +0000 (UTC) Cc: andreas.matthias@gmail.com, 21934@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 22 02:18:18 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 1a0JIG-0002jB-6L for geb-bug-gnu-emacs@m.gmane.org; Sun, 22 Nov 2015 02:18:16 +0100 Original-Received: from localhost ([::1]:54360 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0JIA-0004ad-Gh for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Nov 2015 20:18:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35997) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0JI7-0004aY-CM for bug-gnu-emacs@gnu.org; Sat, 21 Nov 2015 20:18:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0JI2-0006NP-B6 for bug-gnu-emacs@gnu.org; Sat, 21 Nov 2015 20:18:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57779) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0JI2-0006NL-7F for bug-gnu-emacs@gnu.org; Sat, 21 Nov 2015 20:18:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1a0JI1-00028V-Pf for bug-gnu-emacs@gnu.org; Sat, 21 Nov 2015 20:18:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 22 Nov 2015 01:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21934 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21934-submit@debbugs.gnu.org id=B21934.14481550548171 (code B ref 21934); Sun, 22 Nov 2015 01:18:01 +0000 Original-Received: (at 21934) by debbugs.gnu.org; 22 Nov 2015 01:17:34 +0000 Original-Received: from localhost ([127.0.0.1]:47487 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0JHZ-00027i-Cm for submit@debbugs.gnu.org; Sat, 21 Nov 2015 20:17:33 -0500 Original-Received: from mail-wm0-f42.google.com ([74.125.82.42]:35172) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a0JHF-00027H-1P for 21934@debbugs.gnu.org; Sat, 21 Nov 2015 20:17:31 -0500 Original-Received: by wmuu63 with SMTP id u63so16544211wmu.0 for <21934@debbugs.gnu.org>; Sat, 21 Nov 2015 17:17:12 -0800 (PST) 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=8/h/0xHjBsS0mZ+plqxyg65EX1f2NJjTsmmRi5/Xq7I=; b=uORRR/TNzFHEpCwWpM72dbTTWZf5Dc2uFC0sVhR9jfHImbV6jWDvcldvZE88mKsUSx dETyZBaYDFK/ubT73EZ/ZSZp5hsf4A0pNW3kZuSpZW3l5jNgNE+R1HYrQ7ti0sEkUGw9 MYI54Kh0U9gboSspBkVzHNSAq/SOn2Ozi82ge+3rzkW/31EFTOrs5dtVtFC8JUeq842t lH1czQbskPa4ihkGzLfq+/Lo9yd2h7jx+/Aq6FFyqqYVtu80SVzbo0tyiio2cJT/pFwY 3HcT2D9U9OsXLEfIhQGiFfbIdAHG1r7qoSvU4cFlh91WwnCHcC9jYvbifBmYVaPbwIUp zphg== X-Received: by 10.194.78.15 with SMTP id x15mr22564857wjw.144.1448155032492; Sat, 21 Nov 2015 17:17:12 -0800 (PST) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id kw2sm3038559wjb.42.2015.11.21.17.17.11 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 21 Nov 2015 17:17:11 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: <83egfj4i2b.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: 208.118.235.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:109041 Archived-At: On 11/21/2015 03:07 PM, Eli Zaretskii wrote: > Yes, they do. Etags doesn't treat a period '.' as ending an > identifier, except in C-like languages. And that is good, since Lua > evidently wants to support identifiers with embedded periods. In that case, the submitted patch would indeed make things better. However, I wonder if we should rewrite the whole regexp in etags-tags-completion-table, to be more faithful to the "implicit tag" spec, and instead of whitelisting characters that can be used in tags, allow any character in NONAM. (Or rather, I wonder why it hasn't been written that way to begin with, and whether there are some performance pitfalls in doing so). > I've looked at the related code, and my conclusion is that there's > more to this than meets the eye. Indeed. > The OP complained about _completion_ on tag names, and suggested to > fix a regexp used by etags-tags-completion-table. That regexp indeed > doesn't allow a period in an identifier name (probably because it's > disallowed in C-like languages). However, find-tag itself doesn't use > that regexp, If does, for completion. Type M-x find-tag RET TAB, and you'll see the result of calling etags-tags-completion-table. > so typing "M-x find-tag RET Rectangle.getPos RET" finds > that identifier with no problems. That's right: the logic to "list all tags" and to "find tag named xyz" is implemented in different places. And the latter is more faithful to the "implicit tag name" definition; it's the completion table logic that needs to be fixed. > Now, find-tag is deprecated in Emacs 25, and M-. invokes > xref-find-definitions instead. AFAIU, etags-tags-completion-table is > no longer relevant with xref. It's (almost) just as relevant: type C-u M-. TAB. > xref-find-definitions, if it's invoked > with a prefix argument, and if you type "Rectangle.getPos RET" at its > prompt, not surprisingly also finds the identifier. Trying to invoke > completion after "C-u M-.", with test.lua as the current buffer, > doesn't succeed to complete even on Rectangle, so the situation here > is somewhat worse, but I'm not sure why. Is it really any different? M-x find-tag RET TAB doesn't show anything beginning with "Rectangle" either. I only get "getPos" as a completion either way. > If we want "M-." without prefix argument to be able to find these > identifiers, we need first to take care of how it determines the > symbol at point. Currently, it calls (thing-at-point 'symbol), which > predictably guesses wrong. Right, I haven't thought about it. But what else, really, could (xref-backend-identifier-at-point 'etags) return here? It only knows the current buffer's syntax table, and that its data source is etags. Either etags will have to consider that in both example declarations the tag name must be "getPos", not "xxx.getPos", and put this tag name explicitly into the entries, or lua-mode will have to change the syntax class of "." to "symbol", so that (thing-at-point 'symbol) returns "Circle.getPos" as the tag name. That is, of course, if "." always goes after the name of the class/module/etc that "getPos" is defined in, and it can't follow a variable name. I'm not familiar with Lua's syntax.