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, 24 Feb 2022 13:15:41 +0000 Message-ID: References: <1de34060-e93b-0a42-fff5-20e283abe0dc@yandex.ru> <2f41ba40-9c3f-ac65-ef0d-300bd11c4867@yandex.ru> <300e30e1-aeea-ffa5-fa13-d541ccbffe30@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="14453"; 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 Thu Feb 24 14:17:33 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 1nNDzw-0003bf-3t for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 24 Feb 2022 14:17:32 +0100 Original-Received: from localhost ([::1]:43058 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nNDzu-0007oM-09 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 24 Feb 2022 08:17:30 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58274) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nNDzX-0007oA-K1 for bug-gnu-emacs@gnu.org; Thu, 24 Feb 2022 08:17:08 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53938) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nNDzS-0006To-1m for bug-gnu-emacs@gnu.org; Thu, 24 Feb 2022 08:17:07 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nNDzR-0003CO-Jt for bug-gnu-emacs@gnu.org; Thu, 24 Feb 2022 08:17:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: David Fussner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Feb 2022 13:17: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: patch Original-Received: via spool by 53749-submit@debbugs.gnu.org id=B53749.164570856212201 (code B ref 53749); Thu, 24 Feb 2022 13:17:01 +0000 Original-Received: (at 53749) by debbugs.gnu.org; 24 Feb 2022 13:16:02 +0000 Original-Received: from localhost ([127.0.0.1]:47827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nNDyU-0003Ac-5J for submit@debbugs.gnu.org; Thu, 24 Feb 2022 08:16:02 -0500 Original-Received: from mail-qv1-f43.google.com ([209.85.219.43]:42596) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nNDyR-0003A1-Er for 53749@debbugs.gnu.org; Thu, 24 Feb 2022 08:16:00 -0500 Original-Received: by mail-qv1-f43.google.com with SMTP id e22so3382427qvf.9 for <53749@debbugs.gnu.org>; Thu, 24 Feb 2022 05:15:59 -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=34VJV798dzq+MIACZ6DeajURltjRqqv7o55eK8zhapo=; b=lGjj/JYFe9odxEsZmg9SdQrjU2BgFxxTeIUrwdIkZfbDSSB0aF13ngSACxyQDtHWgl jvo4pqhV9Xp+MdirWfrtwhj4Qkiny7obueLxJfbqQHh3S+4pu/+VIqcJgLNjt145tvyl 8X0Zunebyz8fPE/ZlgOtDoIOgJL4+s0H/6PCT8DrkfTAsalyVQIMe2LyNmq/QEca1hZB kho9/Ocq40CAPck/7Rs4ojl2fqfnJS3wDqNY9kinV3L5qy91W5vn8Vq3G/bONTMQSFIO A+vAYEFEuGaZvIGsDnC+ytjvMT6GIi8cMI2pO/bL1rdOXqrKB3Ulinf6H3so7BBXK5Mj HAmA== 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=34VJV798dzq+MIACZ6DeajURltjRqqv7o55eK8zhapo=; b=XZCq+zfEUZC1b+yLKKvqQ1fQpb2GX+vXX96N23cR6bzz5LRbzjlo4DqD5r3CbILu6j YqqSa02KIhcSUGa3axA0msBCPraJDXk/YuHjhcqNzyqhSpGtJfi3Tykf7qXd3/eFtIO6 lK828ZaMnp7F1YQb5vRWhS1VH2q002DztXPGXGWnMO6t7Ct63IM7NZJMpjMDMhXSRNoJ JrMxiTpIUx4BC0CXkgngEOqNyNAq2ZevDVv/nWM9jG1IK67FtdS4O2JHpTeowwOIjWCu F0JSW5thIteJvmvlv2FfMv+NRvDXwWhCl3u0fjGlejB//BPPQ8nEgsRfZ6LBaE60Pirt TB4w== X-Gm-Message-State: AOAM533b+agF82LmfviIC3l2KO2eKZxr/nZH65sDqeGTohrM9MW8r2ih qS8IyLjQBIa/aFPNeoj7Jjmwcw5Rtd2ze6KFcn8= X-Google-Smtp-Source: ABdhPJyrGi8ESvsSKHRHm5NsUlKXeIxhVdq7DCRbcAn2mP/tunFQ21akTAJFVfFdiAmsiPsLyOmoja+kG34P13qbpv8= X-Received: by 2002:ac8:5c4f:0:b0:2dc:8e84:b0ac with SMTP id j15-20020ac85c4f000000b002dc8e84b0acmr2229834qtj.536.1645708553503; Thu, 24 Feb 2022 05:15:53 -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:227583 Archived-At: Thanks Dmitry. I'll post back here when I've got something. David. On Thu, 24 Feb 2022 at 02:23, Dmitry Gutov wrote: > > Hi David, > > On 23.02.2022 12:45, David Fussner via Bug reports for GNU Emacs, the > Swiss army knife of text editors wrote: > > > I guess it might be possible to come up with a regexp to suppress the > > @ in some positions in the string, but the bad news is that if you M-? > > with that search string you get no results at all with the default > > backend. Grep finds the same two as before, but the default format > > specification eliminates even those. So you're left looking at a > > string in your buffer and xref is telling you it isn't there. > > That's odd. I've tried searching for 'blx@opt@uniquename' inside \...@, > and 'grep -w' successfully finds it. Post-processing fails, apparently, > but that depends on the contents of the syntax table. So one solution > might be to update tex-mode's syntax table. > > >> And if not, all in all, I wouldn't worry too much about > >> xref-find-references, since TeX is more of a text format (IMHO) than a > >> program with well-defined identifiers. Perhaps using project-find-regexp > >> most of the time will save you a lot of the trouble? > >> > > > > You're quite right that C-x p g works well in this instance, and I > > tried to improve how thing-at-point finds search strings in TeX > > buffers for this command. I guess TeX is a little bit of a bad fit > > both for text modes and for prog modes, but I confess I'm still uneasy > > at the thought of M-? returning such misleading results. What would > > you think about putting project-find-regexp on M-? in TeX buffers? > > That is, assuming I don't find reasonably common TeX constructs that > > defeat it? > > At the face of it, the suggestion seems odd (those command's features > and user expectations are different), but it wouldn't be out of the > question to circle back to it later. > > >> The parser could create both qualified (with \def or \csdef) and > >> unqualified entries for the same definition. Maybe make it optional > >> (with -Q argument to etags). Then the user could search using any of > >> these formats. > >> > > > > I guess we could make etags do some of the work, perhaps adding also a > > distinction between tagged commands that require this duplication > > (\def & \csdef) and those that don't (\chapter). Aside from making > > tags files a lot bigger, and possibly adding another option to a > > program already overloaded with them -- neither of which is a > > showstopper -- I suspect it could work pretty well for > > xref-find-definitions. > > IIUC tag files for LaTeX aren't going to be particularly big anyway > (book projects are almost always smaller than even a mid-sized software > project), so the size might never be a problem. > > But then again, I could be very wrong about that. > > >> The suggestion about a buffer-local value of that var was made in the > >> context of trying to make it work with the current etags backend. At > >> least, in the first patch. If only because I don't really like to see > >> duplicated code. > >> > >> If we find another place where we really want to diverge, we could also > >> try adding some behavior-altering variable first. > >> > >> After that, we might as well add a new backend (I'm not really against > >> it, just prefer to exhaust other options first), but hopefully someone > >> else (more familiar with tex-mode) could take over this discussion at > >> that point, and the subsequent responsibility for the added code. That > >> person could be yourself too, under right conditions. > > > > I certainly concur about duplicated code, and I really did try hard to > > get by without a new backend, but I won't pretend that I exhausted all > > or even nearly all of the possibilities. If I'm understanding you > > correctly, you'd prefer a few, small changes to the backend code in > > etags.el (and xref.el), should that be necessary, to a whole new > > backend which limits changes to tex-mode.el. If this understanding is > > reasonably accurate, I can have another look at earlier iterations of > > the code to see what I missed, and perhaps come up with something that > > works right without so much duplication. It may well take me some > > time, so apologies in advance for being slow. > > Yes, please.