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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 53749@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>,
>  Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 14 Sep 2023 02:59:33 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> On 13/09/2023 20:01, David Fussner via Bug reports for GNU Emacs, the 
> Swiss army knife of text editors wrote:
> 
> >> These won't be affected either way, right? Because project-find-regexp
> >> defaults its input to (thing-at-point 'symbol t), and isearch...
> >> probably also uses "symbol" if you ask it to.
> >>
> >> So... why not just make tex-thingatpt-include-escape a boolean? What
> >> commands need to be distinguished that way? I think 'find-tag' (it's
> >> obsolete but still used sometimes) would need to obey this var as well.
> > 
> > xref-find-apropos and xref-find-references don't work well (or at all)
> > with the escape char included in the search string, so I was keeping
> > that char away from them. (The buffer-local variables I manipulate for
> > project-find-regexp and isearch-forward-thing-at-point have to do with
> > ensuring they use the texsymbol thing in the first place -- see
> > tex--symbol-or-texsymbol.) Does that make sense?
> 
> Hmm, I suppose I skipped over that part of the patch too quickly.
> 
> Here's a potential problem with replacing the notion of "symbol": some 
> other existing code (also working with TeX/LaTeX) might disagree, as it 
> might have some existing notion of what a "symbol" in those modes is (as 
> defined by the syntax table).
> 
> In general, we change the notion of a symbol by either changing the 
> mode's syntax table, or by augmenting its effect using 
> syntax-propertize-function (which, for example, could propertize the 
> backslashes inside the buffer as "symbol constituent"). The latter might 
> actually be a change that would affect how 'M-x xref-find-references' 
> works (it will likely start to consider those \tags as symbol 
> occurrences together with the backslash). But like other changes of what 
> is considered to be a "symbol" in a major mode, it could conflict with 
> existing code.
> 
> Anyway, I'm not saying you have to change the approach, but that's 
> something to be aware of.
> 
> And to look at it from another direction: if the default implementation 
> of xref-find-references (and etags uses the very generic one) doesn't 
> work for you, perhaps it would be worth it to define a TeX-specific Xref 
> backend. That would perhaps take 20-30 lines of code total, most of them 
> delegating to the etags backend, or the default impl. But while 
> delegating, you can modify the passed argument - e.g. if it included a 
> backslash, you could forward it to the default impl for "find 
> references" without a backslash. Or - alternatively - call 
> (project-find-regexp "...") with a more complex regexp of your choice. 
> The first alternative could look like this:
> 
>    (cl-defmethod xref-backend-references ((_backend (eql 'tex-etags)) 
> identifier)
>      (xref-backend-references 'etags (string-remove-prefix "\\" 
> identifier)))
> 
> > I'll look at find-tag, too; thanks for pointing that out.
> 
> Doing the above choice on the level of Xref backend's methods 
> would/should automatically make it work for all commands appropriately.
> 
> >> Why not set the variable find-tag-default-function instead? That seems
> >> easier and more appropriate to do inside a major mode function.
> > 
> > I settled on putting the symbol on the modes because I thought it was
> > simpler than setting the variable buffer-locally in all the in-tree
> > and AUCTeX modes, but I'll revisit this and see whether I can come up
> > with something better.
> 
> Do AUCTeX modes inherit from tex-mode? Or all call 
> tex-common-initialization? Then you could set that variable locally 
> inside that function once.
> 
> All in all, it might not be wise to modify the behavior of third-party 
> packages from inside Emacs this way (they might have other expectations, 
> or there's going to appear a new major mode that needs the same 
> treatment anyway).
> 
> Setting a variable to be used through mode inheritance or delegation is 
> fine, but if that doesn't help, I would probably stop at defining a 
> helper function or two and documenting how it should be used. And then 
> maybe work with AUCTeX people to get the remaining necessary changes in 
> from their side (or just leaving that up to the user, depending on how 
> functional the default config ends up being).

I think we should add Stefan and Tassilo (CCed) to this discussion, as
they might have valuable comments about this.