From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: David Fussner via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers Date: Thu, 14 Sep 2023 17:11:13 +0100 Message-ID: References: <1de34060-e93b-0a42-fff5-20e283abe0dc@yandex.ru> <87o7vq0zir.fsf@gnus.org> <8735d20yvd.fsf@gnus.org> <2c5c8afa-b57e-3156-d21c-5523cacb4d87@yandex.ru> Reply-To: David Fussner Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18085"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 53749@debbugs.gnu.org, Lars Ingebrigtsen , Stefan Kangas To: Dmitry Gutov , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 14 18:12:20 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 1qgox1-0004Us-WA for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 14 Sep 2023 18:12:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qgowh-0004Lm-Qj; Thu, 14 Sep 2023 12:11: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 1qgowf-0004LJ-Kb for bug-gnu-emacs@gnu.org; Thu, 14 Sep 2023 12:11:58 -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 1qgowe-0004Gc-V5 for bug-gnu-emacs@gnu.org; Thu, 14 Sep 2023 12:11:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qgowk-0007hY-Gu for bug-gnu-emacs@gnu.org; Thu, 14 Sep 2023 12:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: David Fussner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Sep 2023 16:12:02 +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.169470790229575 (code B ref 53749); Thu, 14 Sep 2023 16:12:02 +0000 Original-Received: (at 53749) by debbugs.gnu.org; 14 Sep 2023 16:11:42 +0000 Original-Received: from localhost ([127.0.0.1]:40952 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qgowP-0007gx-Jn for submit@debbugs.gnu.org; Thu, 14 Sep 2023 12:11:42 -0400 Original-Received: from mail-pg1-x52f.google.com ([2607:f8b0:4864:20::52f]:52332) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qgowK-0007gi-VW for 53749@debbugs.gnu.org; Thu, 14 Sep 2023 12:11:40 -0400 Original-Received: by mail-pg1-x52f.google.com with SMTP id 41be03b00d2f7-56b2e689968so908736a12.0 for <53749@debbugs.gnu.org>; Thu, 14 Sep 2023 09:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20221208; t=1694707885; x=1695312685; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yClKgPrgkH0ijtbUZoAa+ts8E01p26jewN3Op7wFT6Y=; b=fppzqFe9Y7Ir216D293aOU2fb6jrVg2m9cIZDy5yn8mK5pEBV8TclBs9qzIpuHZZFU n9F9xrdOLkndpQYxvi8OCgVuip1a5qEmdiB5IT76KcodiEI63aKDz23h2GHMK8XIbJAR HWJnWhmDZHut+4QXSeHG5OTQ7YsMhBHXNf8vaGVwLan29hj8/kA2aQeHY9/Q/dpKqhgH BuAzuWGDE0Ja13/CWhf68Vr2DRJ0bYHEvMY7Nm4mZ9TqdWLtTHr5F2YmP6+VZmv7pgDO 8kvHU6GAySgP/KAiqmuqWvzw0a5DJotmoTm+RUoS5GiFWRVaiVC4f4MpsTOR63vEYgJu e7Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694707885; x=1695312685; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yClKgPrgkH0ijtbUZoAa+ts8E01p26jewN3Op7wFT6Y=; b=XyMvFiAmvd5Sgj8qVKz6LVcKti6FCmS/HMnnye1VNcwZDVaxIwWg1E+URYtosWXO88 llUYpqWLTFKciCYcEES5HTdah2NvpMi25ho574Zm1ez9Y3toPA9VKiCRwogboscmyYWQ z74IWVNq+0yaosmheRpzOrjq5okzuttDdNM6otG/wCHZtbMUQMOJQm1JqCWVuAFBpeqa Vp2uFsah91DEG9berQQe+I8ORtTh6LzTlHgr6TlmFkp2NjNlhTw4sZBIukovHiOEuwBt g5+j76AzyO6MQgj8g9hxpZin3BY9JFvSt/O5eaNRtc+Ea5mha+2Cb6EPj2BncdCKeB/c uiIQ== X-Gm-Message-State: AOJu0YzmZxLiUcw4pL0L1PgcLYipYm3OXFtrF9bF4r9cvNFtgzv7L99E gW8mtY4ioH+b+Qw6gjf2tcShJ2QHMR2V5+mBL3g= X-Google-Smtp-Source: AGHT+IG61FnwSQmCXmH3t+pgdEz698YFKHzZKoflutTzs5z4qykFXSirDm0lhGWH5mF/8XROSnhFCgy/nlH7d9tCGlc= X-Received: by 2002:a17:90b:164d:b0:270:1611:484b with SMTP id il13-20020a17090b164d00b002701611484bmr5433909pjb.41.1694707885068; Thu, 14 Sep 2023 09:11:25 -0700 (PDT) In-Reply-To: <2c5c8afa-b57e-3156-d21c-5523cacb4d87@yandex.ru> 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:270446 Archived-At: Hi Dmitry, 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: 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. 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). Does this sound to you like a plausible way forward? I've tried to reach out to the AUCTeX developers to see what they might want to do about setting the value of local variables there, and anything they come up with should be doable. Thanks again. On Thu, 14 Sept 2023 at 00:59, Dmitry Gutov wrote: > > 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).