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

[David Fussner]

Thanks Dmitry, 

I'll make another stab at a "new" backend, as suggested. I'll have a look at the escape char thing, too, and see how I feel about dropping it. It shouldn't take 18 months this time!

Best,

David. 

On Fri, 15 Sept 2023, 00:55 Dmitry Gutov, <dgutov@yandex.ru> wrote:

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.