bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers

[David Fussner via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Hi Dmitry,

Thanks again for looking at all this, and for your patience.

On Wed, 23 Feb 2022 at 02:21, Dmitry Gutov <dgutov@yandex.ru> wrote:

>
> That might call for a different implementation of 'references' indeed.
>
> But could you make 'blx@opt@uniquename' the default search string in
> that example? Does that make sense?
>

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?

> > If I understand you right, I think that's what I'm trying to do, but
> > allowing for users who perhaps aren't too familiar with emacs regexps
> > and who might typically just accept the default search string offered by
> > xref.
>
> I'm not sure how I feel about the extra "fuzziness" in the behavior
> which comes with this approach.

I see your point here.

>
> 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.

David.