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

[Dmitry Gutov]

Hi David,

On 14/09/2023 19:11, David Fussner via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:

> Once again, many thanks for the feedback. I'm still not certain I
> agree about the risks involved in creating a new "thing" type, as it
> really only appears in a small number of commands and then only in TeX
> buffers, and generally I tried to design the code to keep out of the
> way of anything outside of such buffers, but needless to say you see
> further and more clearly than I can. I've been reviewing your comments
> and my code, and have a few ideas and questions about how to go
> forward. Though I haven't coded it yet, it's possible that the
> simplest (and least intrusive) approach to follow would do something
> like this:

I agree that the risks are probably low, and my review stems from the 
general approach that doing global modifications to the environment can 
lead to problems. It might or might not happen in your case. If anything 
happens, though, the same modifications tend to make it harder to 
investigate, e.g. to find where a particular bit of behavior comes from. 
So the more local an implementation of a feature can be, is generally 
the better.

But I'm no maintainer of tex-mode, and whatever choices are made here 
won't have effect outside of TeX, so if somebody wants to disagree with 
me, they're more than welcome to.

> 1. Get rid of the new texsymbol "thing" and just use a buffer-local
> value of find-tag-default-function and a rather more thoroughly
> modified syntax table to control what "symbol" means, but _only_ in
> the context of commands that use find-tag-default-function. I think
> I'd lose the ability to change the behavior of
> isearch-forward-thing-at-point and project-find-regexp, as I can't see
> how to temporarily modify the syntax table there, though perhaps I'm
> missing something.

I'm suggesting this approach together with defining a "new" backend for 
TeX. Quotes because while it's going to have its own name, it's mostly 
going to perform forwarding to an existing backend (etags).

This should make it practical for you to treat identifiers in 
xref-backend-definitions differently from that in 
xref-backend-references and xref-backend-apropos.

If you define find-tag-default-function, you don't have to change the 
syntax table too: it might be easier to search around with a regexp.

But for the new backend, you can also define the method 
xref-backend-identifier-at-point, where you would invoke the necessary 
bounds-of-thing logic. Then you won't need a change in 
find-tag-default-function.

Either way, though, the major modes will need to set up 
xref-backend-functions instead (with add-hook). This could also be done 
in a minor mode, which you'd enable in any TeX-related major modes that 
you use.

> 2. Simply eliminate the TeX escape character entirely, both from tag
> names in a TAGS file and from any thing-at-point in a TeX buffer. I
> think this would eliminate the need to distinguish among the various
> xref commands in terms of whether they can or can't handle the escape
> character. It would also eliminate the need for the new user option in
> etags.c, as there would no longer be any code to cope with the escape
> character when finding a (thing-at-point 'symbol). This is slightly
> less powerful than the default I proposed, but there are probably many
> use cases where it won't matter at all (though it would for my own,
> possibly eccentric, use case).

I wanted to ask whether including the backslash is important enough (it 
should not matter too much for disambiguation), but I figured it must 
be, otherwise you wouldn't go to all this effort.

If not, it would simplify things a lot, though.