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: Fri, 15 Sep 2023 07:47:29 +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> <891e916e-d05b-b82b-5d3f-148f097d52cc@yandex.ru> Reply-To: David Fussner Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000005bd4030605602bd4" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5089"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 53749@debbugs.gnu.org, Eli Zaretskii , Lars Ingebrigtsen , Stefan Kangas To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 15 08:48:10 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 1qh2cc-00013N-17 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 15 Sep 2023 08:48:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qh2cQ-0001fK-4X; Fri, 15 Sep 2023 02:47:58 -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 1qh2cO-0001dr-57 for bug-gnu-emacs@gnu.org; Fri, 15 Sep 2023 02:47: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 1qh2cN-0006zS-Tf for bug-gnu-emacs@gnu.org; Fri, 15 Sep 2023 02:47:55 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qh2cU-0005js-3D for bug-gnu-emacs@gnu.org; Fri, 15 Sep 2023 02:48: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: Fri, 15 Sep 2023 06:48: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.169476047922039 (code B ref 53749); Fri, 15 Sep 2023 06:48:02 +0000 Original-Received: (at 53749) by debbugs.gnu.org; 15 Sep 2023 06:47:59 +0000 Original-Received: from localhost ([127.0.0.1]:41885 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qh2cQ-0005jL-7M for submit@debbugs.gnu.org; Fri, 15 Sep 2023 02:47:59 -0400 Original-Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]:55385) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qh2cN-0005iR-6J for 53749@debbugs.gnu.org; Fri, 15 Sep 2023 02:47:56 -0400 Original-Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-31fa666000dso1607379f8f.2 for <53749@debbugs.gnu.org>; Thu, 14 Sep 2023 23:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20230601; t=1694760463; x=1695365263; 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=A5VBnLWqFKIETrCgLRfZktivEcRHktust55c5PCG9y8=; b=TRl0GhaAjTqEYPSpxf85IM37qZffkUOebqUhFw4tgSZcOgi+Pf3dQ2BoOzDBbpKc5o ZhhdvrnHEkEnBNOhpfqwUK0cEkNcPeWOeWF+Eg0KA38U9sjOFf9kh8YYrLiCIqvoihzM MA69+sT8IeukGOK9/Q46nnaJIVsZFhYW+n+DXdkXnSM1z3UjoR2tK1U0Ws7ljoHdwnvL URjIEk3ESmNSkFwljyhqe2h/M/17Kc7bQ7JM+HayQUUH0W77nwmv17DTVdruyBKQziZJ 56wD7lib4IPbeOyFFXN4Vjx7Yh/nIaUrkiIoCmuiAETXcOBJoLdAfDKlpiZSK9KBwXdP Bq0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694760463; x=1695365263; 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=A5VBnLWqFKIETrCgLRfZktivEcRHktust55c5PCG9y8=; b=uWhWLvQiOgyy5QYUa7DaXj4CD2H+YHjFIp9hp5BOZxU+70Bb0xSPRW2TKhfVOysLbc 9KWte8G5oqCOtWCGGlHrrpX9M/xgIpj9LuRmnjM2VYYoBP77WO4Avrve6PXSLKbT4EP5 Tro7L9WSym19eMMU04XPW/h0Rkkv8vezltsd692LdkdTeeoAIt9t4Py6ORzDvzUvh0gR XgPdkxC/QZrokjsNX7uaPhJ5CG/upaOGxYdwh6SmPp3oBjupSPdqe2AOue/xNKKkH8lE k9US3c/0ekqVhKWNax1wYZl6sBqORKrqburi0xGAZcxgKtWbaX4BB04RK/v8ea+qEOpg b0Fw== X-Gm-Message-State: AOJu0Yx/loB5P0h7UW485mlpqQAoRoBzE59rNLf4I2/ZkNVVx1pfYiJH ou7+A4uvZvpfRCsUvKEV4/et380HbHI2ojL4T4yh2pPntR8= X-Google-Smtp-Source: AGHT+IHObs5SPCI7PA5ftADb/+NgwkAJtneNrviNGeKFkPChr2X1n302k0cqe2CWgKci3wVYXlrnOfkmM4NA+V2JdFY= X-Received: by 2002:a5d:408b:0:b0:31f:95ec:9099 with SMTP id o11-20020a5d408b000000b0031f95ec9099mr576003wrp.33.1694760462700; Thu, 14 Sep 2023 23:47:42 -0700 (PDT) In-Reply-To: <891e916e-d05b-b82b-5d3f-148f097d52cc@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:270494 Archived-At: --0000000000005bd4030605602bd4 Content-Type: text/plain; charset="UTF-8" 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, 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. > --0000000000005bd4030605602bd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks=C2=A0Dmitry,=C2=A0

I'll make another stab at a "new" backend, as s= uggested. 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.=C2=A0

On Fri, 15 Sept 2023, 00:55 Dmi= try 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<= br> > agree about the risks involved in creating a new "thing" typ= e, 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 comm= ents
> 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 <= br> 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 buffe= r-local
> value of find-tag-default-function and a rather more thoroughly
> modified syntax table to control what "symbol" means, but _o= nly_ 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" b= ackend for
TeX. Quotes because while it's going to have its own name, it's mos= tly
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 <= br> 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 esc= ape
> 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<= br> > character when finding a (thing-at-point 'symbol). This is slightl= y
> 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.
--0000000000005bd4030605602bd4--