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

[David Fussner]

Hi Dmitry,

I found a bit of time to test, and the problem with "@" in command
names appears when a search string for xref-find-references ends with
"@". The results returned will miss out valid hits, depending on what
follows the "@" in the actual command name in the TeX file.

Hope this might help,

David.

On Mon, 21 Feb 2022 at 09:48, David Fussner <dfussner@googlemail.com> wrote:
>
> (Resending to include the mailing list -- sorry!)
>
> Hi Dmitry,
>
> Many thanks for looking into this.
>
> >
> > So if your main goal was to alter which string gets searched for (based
> > on text around point), you can define a function which returns the
> > necessary string (as you did in the patch) and then either set
> > 'find-tag-default-function' to that function, or put it on the
> > 'find-tag-default-function' property for the respective major mode
> > functions.
> >
> > > There are many other behaviors that are suboptimal, as well, so in the
> > > end I wrote a new xref backend for TeX buffers (cloning large portions
> > > of the default etags backend), and wondered whether it might be welcome
> > > in GNU Emacs.
> >
> > Could you point out the other changes which were required?
>
> As you've noticed, I tried at first to get by without a new backend,
> but I ran into a few issues that I couldn't solve that way, hence the
> current patch.  A couple of examples:
>
> 1. TeX is very generous with the characters it includes in its
> symbols, so what looks like a standard symbol to it can look like a
> regexp either to grep or to emacs, so I needed to changes things in
> xref-find-apropos and in xref-find-references to take this into
> account.  (See tex-xref-apropos-regexp and
> tex-xref-references-in-directory.)  Sometimes using a search string
> that had been put through regexp-quote was wrong, as when a user
> provided their own regexp in the minibuffer, so in both those cases I
> provided fallbacks to a different search in case the default search
> came up empty.  I couldn't see how to do this without a new backend.
>
> 2.  A package like biblatex creates what amounts to a separate
> namespace using the \newbibmacro mechanism, so pretty much every
> biblatex style has both a \cite command and a cite bibmacro, and I
> wanted to allow emacs to differentiate between them when using
> xref-find-definitions.  Because users of the etoolbox package (like
> biblatex) may well mix commands with and without the escape char "\",
> I also provided a variable to allow users to find when a \command is
> called using \csuse{command} instead.  Again, this required a fallback
> search (see xref-backend-definitions) which I couldn't see how to
> provide without a new backend.
>
> Does this make any sense?  I can give more specific examples if you
> like -- try running xref-find-references on a TeX command with "@" in
> it.  (If memory serves, that behaved badly here on an unpatched emacs,
> but maybe I'm misremembering.)
>
> David.
>
> On Mon, 21 Feb 2022 at 02:11, Dmitry Gutov <dgutov@yandex.ru> wrote:
> >
> > Hi!
> >
> > Let us first discuss whether we could make do without an additional Xref
> > backend. Just to make sure.
> >
> > On 03.02.2022 17:09, David Fussner via Bug reports for GNU Emacs, the
> > Swiss army knife of text editors wrote:
> > > Similarly, any xref command on 'my:citekey' will only search by default
> > > for the half of the symbol under point, stopping at the colon.
> >
> > etags's implementation of 'xref-backend-identifier-at-point' calls
> > 'find-tag--default', which consults 'find-tag-default-function' and
> > (get major-mode 'find-tag-default-function).
> >
> > So if your main goal was to alter which string gets searched for (based
> > on text around point), you can define a function which returns the
> > necessary string (as you did in the patch) and then either set
> > 'find-tag-default-function' to that function, or put it on the
> > 'find-tag-default-function' property for the respective major mode
> > functions.
> >
> > > There are many other behaviors that are suboptimal, as well, so in the
> > > end I wrote a new xref backend for TeX buffers (cloning large portions
> > > of the default etags backend), and wondered whether it might be welcome
> > > in GNU Emacs.
> >
> > Could you point out the other changes which were required?