I guess it might be possible to come up with a regexp to suppress the
@ in some positions in the string, but the bad news is that if you M-?
with that search string you get no results at all with the default
backend. Grep finds the same two as before, but the default format
specification eliminates even those. So you're left looking at a
string in your buffer and xref is telling you it isn't there.
And if not, all in all, I wouldn't worry too much about
xref-find-references, since TeX is more of a text format (IMHO) than a
program with well-defined identifiers. Perhaps using project-find-regexp
most of the time will save you a lot of the trouble?
You're quite right that C-x p g works well in this instance, and I
tried to improve how thing-at-point finds search strings in TeX
buffers for this command. I guess TeX is a little bit of a bad fit
both for text modes and for prog modes, but I confess I'm still uneasy
at the thought of M-? returning such misleading results. What would
you think about putting project-find-regexp on M-? in TeX buffers?
That is, assuming I don't find reasonably common TeX constructs that
defeat it?
The parser could create both qualified (with \def or \csdef) and
unqualified entries for the same definition. Maybe make it optional
(with -Q argument to etags). Then the user could search using any of
these formats.
I guess we could make etags do some of the work, perhaps adding also a
distinction between tagged commands that require this duplication
(\def & \csdef) and those that don't (\chapter). Aside from making
tags files a lot bigger, and possibly adding another option to a
program already overloaded with them -- neither of which is a
showstopper -- I suspect it could work pretty well for
xref-find-definitions.
The suggestion about a buffer-local value of that var was made in the
context of trying to make it work with the current etags backend. At
least, in the first patch. If only because I don't really like to see
duplicated code.
If we find another place where we really want to diverge, we could also
try adding some behavior-altering variable first.
After that, we might as well add a new backend (I'm not really against
it, just prefer to exhaust other options first), but hopefully someone
else (more familiar with tex-mode) could take over this discussion at
that point, and the subsequent responsibility for the added code. That
person could be yourself too, under right conditions.
I certainly concur about duplicated code, and I really did try hard to
get by without a new backend, but I won't pretend that I exhausted all
or even nearly all of the possibilities. If I'm understanding you
correctly, you'd prefer a few, small changes to the backend code in
etags.el (and xref.el), should that be necessary, to a whole new
backend which limits changes to tex-mode.el. If this understanding is
reasonably accurate, I can have another look at earlier iterations of
the code to see what I missed, and perhaps come up with something that
works right without so much duplication. It may well take me some
time, so apologies in advance for being slow.