From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Augusto Stoffel Newsgroups: gmane.emacs.bugs Subject: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers Date: Fri, 25 Feb 2022 21:16:16 +0100 Message-ID: <87pmnad7n3.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16601"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) Cc: dfussner@googlemail.com To: 53749@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Feb 25 21:17:14 2022 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 1nNh1e-00044H-KW for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 25 Feb 2022 21:17:14 +0100 Original-Received: from localhost ([::1]:52506 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nNh1d-0007DI-Fd for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 25 Feb 2022 15:17:13 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:51024) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nNh1S-0007AR-Dg for bug-gnu-emacs@gnu.org; Fri, 25 Feb 2022 15:17:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59917) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nNh1S-0000Ue-4b for bug-gnu-emacs@gnu.org; Fri, 25 Feb 2022 15:17:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nNh1S-0008L7-23 for bug-gnu-emacs@gnu.org; Fri, 25 Feb 2022 15:17:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Augusto Stoffel Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 25 Feb 2022 20:17: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: patch X-Debbugs-Original-To: David Fussner via "Bug reports for GNU Emacs, the Swiss army knife of text editors" X-Debbugs-Original-Cc: 53749@debbugs.gnu.org, David Fussner Original-Received: via spool by 53749-submit@debbugs.gnu.org id=B53749.164582018631982 (code B ref 53749); Fri, 25 Feb 2022 20:17:02 +0000 Original-Received: (at 53749) by debbugs.gnu.org; 25 Feb 2022 20:16:26 +0000 Original-Received: from localhost ([127.0.0.1]:53810 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nNh0s-0008Jm-44 for submit@debbugs.gnu.org; Fri, 25 Feb 2022 15:16:26 -0500 Original-Received: from mail-ed1-f54.google.com ([209.85.208.54]:39919) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nNh0q-0008JX-DA for 53749@debbugs.gnu.org; Fri, 25 Feb 2022 15:16:25 -0500 Original-Received: by mail-ed1-f54.google.com with SMTP id g20so8941764edw.6 for <53749@debbugs.gnu.org>; Fri, 25 Feb 2022 12:16:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=pOtJY65BSCDg5reHSC+XupwZ0t80w4yz2ZVZg70/NPM=; b=GYXELjg/pBo6hQT+aJ2L4VV4TUtbiGFSqxvajZZtkkqXAT6grRQomHjllLI2UwyIAS 5hlPH0P0ZUOhMvLopGT7t5+Qbjoe8DwbU5evHdWNi2ZbZyP1/oFFyTgEuiDSKCEhF+CN qrsYdiaAVyqtuTUu4W+PoQNjOJF0g2arS2eKDRA7L0fGSp8nHh3BbrhrKJXtLmqyhsZH XC4uKyvHE18rj12RNpKUyy7uv23k88h7JBWdQJ+Gyiq2sidgnAswEQKK/meMPbRTefUp O3V8hQq/9p+mgeigZleCgHlNBK8rxIT6BQDPgVzM+AFjplARx+l0dJtoThhqY7vPLYvl 08ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=pOtJY65BSCDg5reHSC+XupwZ0t80w4yz2ZVZg70/NPM=; b=XyXvWQDqpaxWyKM0iAZApEPyKmjKEg3TBwUQvHLCbwvoRHz0MP61IFEO7maC5ZC+Ng qSX2LY78xBTwecHld4KwYazbJdtnG/7m5KHIUqTw1/W9ELTNgAy8rPOMIM4y5qipPjUE pW6rMRdn8jDA+qxcTZuVE52P9B0yOJGA9a1jwzBAlj4Eun8L2uRGSiS/R6RgqfvCkMLJ TpXCky0pQRxoxtfQAXNnLYeTcSzA3V0v1HYNcdt8rxC7yH4gsyauEyaleSb47Esr0FcE NTGsNKWz475cz9ElmT5NaZyl59RFwx1nzCKiH7X6oNbAHmiNz9AGepnTHRNP6NxoWyT4 cK/A== X-Gm-Message-State: AOAM533YSleFgFPKLsjcJJgfonGoAgbfTHvv3DzXKkCi+FXZFetz/t2i a/V2AzU/6zPYCxWKOpLDf1s= X-Google-Smtp-Source: ABdhPJzkrNg5/WBOm2QpdYQfT2LHEAhiHWZc3ImETfIBiHNhwVOdJZUb6waM9FYAvPWOmXgDfKgHNw== X-Received: by 2002:a50:ee90:0:b0:40f:349f:7368 with SMTP id f16-20020a50ee90000000b0040f349f7368mr8488283edr.236.1645820178223; Fri, 25 Feb 2022 12:16:18 -0800 (PST) Original-Received: from ars3 ([2a02:8109:8ac0:56d0::758e]) by smtp.gmail.com with ESMTPSA id n23-20020a509357000000b00412b325b05fsm1750361eda.74.2022.02.25.12.16.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Feb 2022 12:16:17 -0800 (PST) In-Reply-To: (David Fussner via's message of "Thu, 3 Feb 2022 15:09:22 +0000") 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" Xref: news.gmane.io gmane.emacs.bugs:227648 Archived-At: Hi David, I took a superficial look at this thread, and this seems very nice. I was wondering why you want to be able to find the definition of macros with @ in their name. Those are "private" macros that the user shouldn't have occasion to use. Is it for a TeX programmer mode? Let me also mention a library I wrote for analyzing TeX code (accessible to Emacs via LSP): https://github.com/astoff/digestif It's written in Lua (can run on the LuaTeX interpreter) and uses PEGs for flexible parsing. If you want to be very ambitious about what you are able to parse, I think regexps are not sufficient. Digestif can handle \cite{messed up reference} just fine, for example. On Thu, 3 Feb 2022 at 15:09, David Fussner via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote: > I've recently been trying to use xref commands with a tags table in a > TeX repository, and many of the results are sub-optimal. This is a > known issue -- within living memory there have been at least two > discussions related to it on help-gnu-emacs: > > https://lists.gnu.org/archive/html/help-gnu-emacs/2018-06/msg00126.html > https://lists.gnu.org/archive/html/help-gnu-emacs/2021-07/msg00436.html > > Neither discussion resulted in any code, at least not that I can find, > and the issues mentioned there remain. For example, > xref-find-definitions on, say, '\mycommand' returns > > No definitions found for: mycommand. > > (The absence of the escape char in the search string makes the search > fail, as the tag name in the table will be '\mycommand'.) > > Similarly, any xref command on 'my:citekey' will only search by default > for the half of the symbol under point, stopping at the colon. > > There are many other behaviors that are suboptimal, as well, so in the > end I wrote a new xref backend for TeX buffers (cloning large portions > of the default etags backend), and wondered whether it might be welcome > in GNU Emacs. > > A few remarks: > > 1. The code should work as it stands both in the AUCTeX and the in-tree > modes. The AUCTeX hooks I've included in the patch are provisional, as > I would want to discuss with them how they would want to handle it, > should the patch be accepted in some form. > > 2. Along the way I found some issues with how etags parses TeX files, > issues which affect the usefulness of the xref commands, so I've made > changes in etags.c as well. When running the test suite for etags the > only diffs occurred in the TeX-related sections of the resulting tags > file, and location information in those sections was good. > > 3. The patch as it stands enables all the changes by default to give > what I judge to be the best out-of-the-box experience, but wiser heads > may well have other ideas. > > 4. If it looks like the patch will make it into Emacs in some form, I'm > going to need to assign copyright, so I'd appreciate help with getting > that started. > > Thanks, > > David.