GNU bug report logs - #53749
29.0.50; [PATCH] Xref backend for TeX buffers

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>, Stefan Monnier <monnier <at> iro.umontreal.ca>, Tassilo Horn <tsdh <at> gnu.org>
Cc: 53749 <at> debbugs.gnu.org, larsi <at> gnus.org, stefankangas <at> gmail.com, dfussner <at> googlemail.com
Subject: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
Date: Thu, 14 Sep 2023 09:10:06 +0300

> Cc: 53749 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
>  Stefan Kangas <stefankangas <at> gmail.com>
> Date: Thu, 14 Sep 2023 02:59:33 +0300
> From: Dmitry Gutov <dgutov <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.