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

Thanks Dmitry.  I'll post back here when I've got something.

David.

On Thu, 24 Feb 2022 at 02:23, Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> Hi David,
>
> On 23.02.2022 12:45, David Fussner via Bug reports for GNU Emacs, the
> Swiss army knife of text editors wrote:
>
> > 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.
>
> That's odd. I've tried searching for 'blx@opt@uniquename' inside \...@,
> and 'grep -w' successfully finds it. Post-processing fails, apparently,
> but that depends on the contents of the syntax table. So one solution
> might be to update tex-mode's syntax table.
>
> >> 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?
>
> At the face of it, the suggestion seems odd (those command's features
> and user expectations are different), but it wouldn't be out of the
> question to circle back to it later.
>
> >> 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.
>
> IIUC tag files for LaTeX aren't going to be particularly big anyway
> (book projects are almost always smaller than even a mid-sized software
> project), so the size might never be a problem.
>
> But then again, I could be very wrong about that.
>
> >> 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.
>
> Yes, please.