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

[David Fussner]

(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?