bug#22692: 25.0.91; xref-find-definitions fails to prompt

[Dmitry Gutov]

On 02/17/2016 03:55 AM, Mike Kupfer wrote:

> The Help string for xref-find-definitions says
>
> > With prefix argument or when there’s no identifier at point,
> > prompt for it.
>
> I guess you could argue that if point is on a token that's not in the
> tags table, it's still on an "identifier".

Whatever identifier the backend says is there. Which, in the case of 
etags, delegates to find-tag--default.

Validating identifiers against the tags table is a sensible suggestion, 
but that might backfire in several scenarios:

- What if the tags table only contains fully qualified names? We have 
multiple ways the backend can match tags, defined by 
etags-xref-find-definitions-tag-order, which might apply even if the 
identifier is not literally one of the elements.

And I'm not sure performing that matching logic just when the default 
identifier to use is returned, is a good idea.

- Either xref-backend-identifier-at-point impl for etags will have to be 
able to use different logic based on the command currently being invoked 
(that doesn't really fit in the current design), or you won't be able to 
look for e.g. occurrences of the local variable at point (using 
xref-find-references), because etags doesn't parse local variables.

> But "#" is hardly an identifier.

Apparently it is, as far as find-tag-default-bounds is concerned. In the 
following sense: find-tag-default-bounds uses the notion of "symbol" as 
defined by the current syntax table.

If "#" can't be a part of an identifier name in the programming language 
in question (C, right?), maybe you should request that character's 
syntax class to be changed to something like "punctuation" there.

> Does "valid identifier" mean syntatically correct, or does it mean that
> the identifier is in the tags table.  Please clarify the documentation.

We probably should just remove the word "valid" from there.