From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers Date: Thu, 14 Sep 2023 09:10:06 +0300 Message-ID: <831qf1mgjl.fsf@gnu.org> References: <1de34060-e93b-0a42-fff5-20e283abe0dc@yandex.ru> <87o7vq0zir.fsf@gnus.org> <8735d20yvd.fsf@gnus.org> <2c5c8afa-b57e-3156-d21c-5523cacb4d87@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22709"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 53749@debbugs.gnu.org, larsi@gnus.org, stefankangas@gmail.com, dfussner@googlemail.com To: Dmitry Gutov , Stefan Monnier , Tassilo Horn Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 14 08:11:16 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qgfZH-0005gS-RL for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 14 Sep 2023 08:11:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qgfZ5-00071U-RO; Thu, 14 Sep 2023 02:10:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qgfZ2-0006xm-Tn for bug-gnu-emacs@gnu.org; Thu, 14 Sep 2023 02:10:56 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qgfZ2-00071J-0l for bug-gnu-emacs@gnu.org; Thu, 14 Sep 2023 02:10:56 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qgfZ7-00057E-Kq for bug-gnu-emacs@gnu.org; Thu, 14 Sep 2023 02:11:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Sep 2023 06:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53749 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: pending patch Original-Received: via spool by 53749-submit@debbugs.gnu.org id=B53749.169467183519614 (code B ref 53749); Thu, 14 Sep 2023 06:11:01 +0000 Original-Received: (at 53749) by debbugs.gnu.org; 14 Sep 2023 06:10:35 +0000 Original-Received: from localhost ([127.0.0.1]:36614 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qgfYg-00056I-CX for submit@debbugs.gnu.org; Thu, 14 Sep 2023 02:10:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59350) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qgfYd-000562-FL for 53749@debbugs.gnu.org; Thu, 14 Sep 2023 02:10:33 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qgfYR-0006gD-RR; Thu, 14 Sep 2023 02:10:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=xntW5xfSLhAMvBSsazXkTqy2XzPg9UBcKv0LOUQ72GA=; b=Yf4KfEUyg1HR 1XXBX4mTITRHzO30bmG0bwnKp5SJH568fmrfvNqR4NtXnqVej+elNMR/sf+aXumXAi9cQA5w3Szso HFwjQ6wljyvvuEybTtfe8Q+g+pPEddX5C5ioPIyxNmLpaq9uE+8vtHP8DhAebjNPU9YahKiBheZMk lfR3E5mNV22FAOoBqrGjkSzlK+igASA2d7CEWMJa10cQb3mbKqvqr/IZlVNkJVJfFKWDdvrAwSvwI tJ+TDpDexCzYkhPqJNsOqExdCCvJQ1H4UMrvAVv95qBy633kDzbZlv3mD1XzoDWJDyYLMHtaQGmee 9+5eGRMa7J1KzwLkIKjmew==; In-Reply-To: <2c5c8afa-b57e-3156-d21c-5523cacb4d87@yandex.ru> (message from Dmitry Gutov on Thu, 14 Sep 2023 02:59:33 +0300) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:270397 Archived-At: > Cc: 53749@debbugs.gnu.org, Lars Ingebrigtsen , > Stefan Kangas > Date: Thu, 14 Sep 2023 02:59:33 +0300 > From: Dmitry Gutov > > 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.