[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22292: 25.0.50; xref-find-references doesn't find anything for Lisp
From: |
Dmitry Gutov |
Subject: |
bug#22292: 25.0.50; xref-find-references doesn't find anything for Lisp symbols |
Date: |
Sat, 2 Jan 2016 16:05:33 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Thunderbird/43.0 |
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.