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: Mon, 21 Feb 2022 17:28:32 +0000 Message-ID: References: <1de34060-e93b-0a42-fff5-20e283abe0dc@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="29582"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 53749@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 21 18:37:16 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 1nMCce-0007UR-Co for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Feb 2022 18:37:16 +0100 Original-Received: from localhost ([::1]:49180 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nMCcc-00028I-Vr for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Feb 2022 12:37:15 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:51298) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nMCUh-0007hY-00 for bug-gnu-emacs@gnu.org; Mon, 21 Feb 2022 12:29:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44993) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nMCUg-00005D-L7 for bug-gnu-emacs@gnu.org; Mon, 21 Feb 2022 12:29:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nMCUg-00045P-Fl for bug-gnu-emacs@gnu.org; Mon, 21 Feb 2022 12:29:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: David Fussner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Feb 2022 17:29: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 Original-Received: via spool by 53749-submit@debbugs.gnu.org id=B53749.164546453315686 (code B ref 53749); Mon, 21 Feb 2022 17:29:02 +0000 Original-Received: (at 53749) by debbugs.gnu.org; 21 Feb 2022 17:28:53 +0000 Original-Received: from localhost ([127.0.0.1]:38889 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nMCUW-00044u-MC for submit@debbugs.gnu.org; Mon, 21 Feb 2022 12:28:53 -0500 Original-Received: from mail-qk1-f182.google.com ([209.85.222.182]:36834) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nMCUV-00044j-8h for 53749@debbugs.gnu.org; Mon, 21 Feb 2022 12:28:51 -0500 Original-Received: by mail-qk1-f182.google.com with SMTP id g24so17621680qkl.3 for <53749@debbugs.gnu.org>; Mon, 21 Feb 2022 09:28:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BCBkOuF/XYtWwt5r1aCpOf2Q0hFDUAio+xUcfMIxueM=; b=pqZ8Ks7PTPJXJcnVCbGzUaTf8T+NYXYca530XnLhMQPo3wtic9XfeXjvF7MMzmCBEZ QaZTcZnQlJfr6g4UF3FFfhmVjkBBS0XeP3To0LmEcoyCZHfQoANw6EVOs6FGiKLFg4oV /hBH9JQVu5N7a4qTQtWIGEjqsMA/aMv2cP9h0Ya5YDhs+0NwnH1Q6qdhInpfvZkEu35C FQnheptHqjMtTFzIR3PoVFvTjYlxLtZ5ucSjnd/JjtOOZo4HfhUW6LV8pLdRLOzhzQ04 7VApmmWXQr66c/OqPZLUpiLffpyAEdcZPV3HhMlkGDKnxEiz7NIUJfApeCkLlLtxh7RV MaAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BCBkOuF/XYtWwt5r1aCpOf2Q0hFDUAio+xUcfMIxueM=; b=KLxGn2g2KZHuT+uix7aRh4DpFRefAze0AXBsu8vMF2rSjd2frxOTjWpN5OrK0XxGMt 0B4iu1hjgac/iHTmZHNt/OdQe+66Tn8DyET/IIE9tMjLtoee+TrUW8KhFKGkgJZtwZ+4 qp+h887njnFwC3OmljgU9pdTFCp4daVK0quNYqj7ZGfkaBAcU7M9YUfcH24zs29YvTvd 8mRpEusG/mPiCGgkfJDKeTrD/lFQBBzJl0WSwycxH3owvq2X21ldy2tCNc8SezuIy69W Xm76mwr7PBLa9+wj81c0KIaho98qqXRwuJdcgjiPT5uOsb4UhZdwgHgDxewBWMU9o6gA qNxw== X-Gm-Message-State: AOAM532hYy3TgkCp7am54D3Arl0HHFGU8aOEN6ct46SIGKyE1/XyVpLt paBB9X5fIPFj5UmdTCRonpIULsu08ueiV4xjtVA= X-Google-Smtp-Source: ABdhPJwVP7clZeBYCb50fHFvHEzIjmyckuv0OYccVW97cztK1zc/P22+/bG1p77yhGjTV2xSfrL7eiBsDtUgIN5O+Uk= X-Received: by 2002:a37:4147:0:b0:47c:4595:b8c with SMTP id o68-20020a374147000000b0047c45950b8cmr12878581qka.267.1645464525701; Mon, 21 Feb 2022 09:28:45 -0800 (PST) In-Reply-To: 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:227374 Archived-At: Hi Dmitry, I found a bit of time to test, and the problem with "@" in command names appears when a search string for xref-find-references ends with "@". The results returned will miss out valid hits, depending on what follows the "@" in the actual command name in the TeX file. Hope this might help, David. On Mon, 21 Feb 2022 at 09:48, David Fussner wrote: > > (Resending to include the mailing list -- sorry!) > > Hi Dmitry, > > Many thanks for looking into this. > > > > > So if your main goal was to alter which string gets searched for (based > > on text around point), you can define a function which returns the > > necessary string (as you did in the patch) and then either set > > 'find-tag-default-function' to that function, or put it on the > > 'find-tag-default-function' property for the respective major mode > > functions. > > > > > 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. > > > > Could you point out the other changes which were required? > > As you've noticed, I tried at first to get by without a new backend, > but I ran into a few issues that I couldn't solve that way, hence the > current patch. A couple of examples: > > 1. TeX is very generous with the characters it includes in its > symbols, so what looks like a standard symbol to it can look like a > regexp either to grep or to emacs, so I needed to changes things in > xref-find-apropos and in xref-find-references to take this into > account. (See tex-xref-apropos-regexp and > tex-xref-references-in-directory.) Sometimes using a search string > that had been put through regexp-quote was wrong, as when a user > provided their own regexp in the minibuffer, so in both those cases I > provided fallbacks to a different search in case the default search > came up empty. I couldn't see how to do this without a new backend. > > 2. A package like biblatex creates what amounts to a separate > namespace using the \newbibmacro mechanism, so pretty much every > biblatex style has both a \cite command and a cite bibmacro, and I > wanted to allow emacs to differentiate between them when using > xref-find-definitions. Because users of the etoolbox package (like > biblatex) may well mix commands with and without the escape char "\", > I also provided a variable to allow users to find when a \command is > called using \csuse{command} instead. Again, this required a fallback > search (see xref-backend-definitions) which I couldn't see how to > provide without a new backend. > > Does this make any sense? I can give more specific examples if you > like -- try running xref-find-references on a TeX command with "@" in > it. (If memory serves, that behaved badly here on an unpatched emacs, > but maybe I'm misremembering.) > > David. > > On Mon, 21 Feb 2022 at 02:11, Dmitry Gutov wrote: > > > > Hi! > > > > Let us first discuss whether we could make do without an additional Xref > > backend. Just to make sure. > > > > On 03.02.2022 17:09, David Fussner via Bug reports for GNU Emacs, the > > Swiss army knife of text editors wrote: > > > Similarly, any xref command on 'my:citekey' will only search by default > > > for the half of the symbol under point, stopping at the colon. > > > > etags's implementation of 'xref-backend-identifier-at-point' calls > > 'find-tag--default', which consults 'find-tag-default-function' and > > (get major-mode 'find-tag-default-function). > > > > So if your main goal was to alter which string gets searched for (based > > on text around point), you can define a function which returns the > > necessary string (as you did in the patch) and then either set > > 'find-tag-default-function' to that function, or put it on the > > 'find-tag-default-function' property for the respective major mode > > functions. > > > > > 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. > > > > Could you point out the other changes which were required?