bug#22292: 25.0.50; xref-find-references doesn't find anything for Lisp symbols

[Dmitry Gutov <dgutov@yandex.ru>]

Hi Eli,

On 01/02/2016 03:23 PM, Eli Zaretskii wrote:
> To reproduce:
>
>    emacs -Q
>    C-x C-f lisp/subr.el RET
>    M-? executing-kbd-macro RET

This scenario works for me, and I get ~100 matches, with emacs-25 HEAD.

> The result is disappointing:
>
>    No references found for: executing-kbd-macro
>
> The equivalent command in a C buffer (for a C symbol) does work as
> expected.

I'd expect the problem to be OS-specific, but it working in C buffers is 
clearly odd. You should be able to edebug xref-collect-references to see 
what happens (*).

> I'm guessing that something is missing in the Lisp xref back-end that
> doesn't let us support this operation.  However, I don't think we can
> ship Emacs 25.1 with such an omission.  Lisp is one of the 2 languages
> in which Emacs is written, so we ought to support it well.

Agreed.

> Can someone please implement the necessary functionality on the
> emacs-25 branch?  Bonus points for doing that for a few more popular
> languages for which we have support in lisp/progmodes/.

The implementation is largely language-agnostic. Basically, it greps, 
and then checks the returned hits for matches for 
"\\_<executing-kbd-macro\\_>".

Which depends on each buffer's syntax table and 
syntax-propertize-function. We are going to encounter cases where the 
"current symbol" is detected wrong due to this heuristic, but the fixes 
will probably go into syntax tables and s-p-function values.

(*) However (!), for xref-find-references only, we delegate to 
semantic-symref-find-references-by-name. And it might call any of the 
registered tools (such as id-utils), if the respective database file is 
present.

Might it be that id-utils doesn't parse Elisp files? If you recall, I 
mentioned this as a source of a possible user confusion. I don't know 
how to make it friendlier.

> (This came up in the context of rewriting the "Tags Tables" section of
> the user manual, where etags.el functionality now takes a back seat to
> xref.el.  Part of that is documenting the xref-find-references
> command.

To be fair, we could leave xref-find-references unadvertised, because 
it's not replacing any of the existing etags commands. But yeah, it 
should work.