all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: andreas.matthias@gmail.com, 21934@debbugs.gnu.org
Subject: bug#21934: 24.5; find-tag: reading TAGS file incorrectly
Date: Sun, 22 Nov 2015 03:17:09 +0200	[thread overview]
Message-ID: <56511795.2050207@yandex.ru> (raw)
In-Reply-To: <83egfj4i2b.fsf@gnu.org>

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.





  reply	other threads:[~2015-11-22  1:17 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-16 19:47 bug#21934: 24.5; find-tag: reading TAGS file incorrectly Andreas Matthias
2015-11-17  4:01 ` Dmitry Gutov
2015-11-17 16:06   ` Eli Zaretskii
2015-11-17 17:21   ` Andreas Matthias
2015-11-17 17:24     ` Dmitry Gutov
2015-11-17 17:40       ` Andreas Matthias
2015-11-17 17:46         ` Dmitry Gutov
2015-11-17 19:38           ` Andreas Matthias
2015-11-18  1:56             ` Dmitry Gutov
2015-11-21 13:07   ` Eli Zaretskii
2015-11-22  1:17     ` Dmitry Gutov [this message]
2015-11-22  4:38       ` Dmitry Gutov
2015-11-22 14:08       ` Andreas Matthias
2015-11-22 14:33         ` Dmitry Gutov
2015-11-22 14:41           ` Dmitry Gutov
2015-11-22 15:06           ` Andreas Matthias
2015-11-22 15:23             ` Dmitry Gutov
2015-11-22 16:41               ` Andreas Matthias
2015-11-22 16:43                 ` Dmitry Gutov
2015-11-22 16:12       ` Eli Zaretskii
2015-11-22 16:54         ` Dmitry Gutov
2015-11-22 17:38           ` Eli Zaretskii
2015-11-22 17:43             ` Dmitry Gutov
2015-11-22 17:49               ` Andreas Matthias
2015-11-22 18:13                 ` Eli Zaretskii
2015-11-23 16:50                   ` Andreas Matthias
2015-11-23 17:16                     ` Eli Zaretskii
2015-11-23 17:28                       ` Andreas Matthias
2015-11-23 18:17                         ` Eli Zaretskii
2015-11-28 10:33                           ` Eli Zaretskii
2015-11-28 17:25                             ` Andreas Matthias
2015-11-30 17:34                               ` Eli Zaretskii
2015-11-28 17:25                             ` Andreas Matthias
2015-11-22 18:09               ` Eli Zaretskii
2015-11-22 18:27                 ` Andreas Matthias
2015-11-22 18:33                   ` Dmitry Gutov
2015-11-22 18:52                     ` Andreas Matthias
2015-11-26  2:41       ` Dmitry Gutov
2015-11-17 11:05 ` Stephen Leake
2015-11-17 17:17   ` Andreas Matthias

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56511795.2050207@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=21934@debbugs.gnu.org \
    --cc=andreas.matthias@gmail.com \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.