From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers Date: Thu, 24 Feb 2022 04:23:48 +0200 Message-ID: References: <1de34060-e93b-0a42-fff5-20e283abe0dc@yandex.ru> <2f41ba40-9c3f-ac65-ef0d-300bd11c4867@yandex.ru> <300e30e1-aeea-ffa5-fa13-d541ccbffe30@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16387"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Cc: 53749@debbugs.gnu.org To: David Fussner Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Feb 24 03:24:17 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 1nN3nl-00049b-Of for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 24 Feb 2022 03:24:17 +0100 Original-Received: from localhost ([::1]:57424 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nN3nk-00072B-Bw for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Feb 2022 21:24:16 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40474) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nN3nY-00071q-94 for bug-gnu-emacs@gnu.org; Wed, 23 Feb 2022 21:24:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53045) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nN3nW-0001sB-Hu for bug-gnu-emacs@gnu.org; Wed, 23 Feb 2022 21:24:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nN3nW-00081b-D7 for bug-gnu-emacs@gnu.org; Wed, 23 Feb 2022 21:24:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Feb 2022 02:24: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.164566943830838 (code B ref 53749); Thu, 24 Feb 2022 02:24:02 +0000 Original-Received: (at 53749) by debbugs.gnu.org; 24 Feb 2022 02:23:58 +0000 Original-Received: from localhost ([127.0.0.1]:46942 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nN3nS-00081K-9k for submit@debbugs.gnu.org; Wed, 23 Feb 2022 21:23:58 -0500 Original-Received: from mail-wr1-f46.google.com ([209.85.221.46]:42529) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nN3nQ-000815-Id for 53749@debbugs.gnu.org; Wed, 23 Feb 2022 21:23:57 -0500 Original-Received: by mail-wr1-f46.google.com with SMTP id d17so738180wrc.9 for <53749@debbugs.gnu.org>; Wed, 23 Feb 2022 18:23:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=nm2/jvARW/kXJfePE75YpDEu86GSmMahZJxlHqZ+nOo=; b=TnjEHtBdEAwK+rH+QhPcroEGubcqPo0q88lo9uvR5ijEDtiyfURmcKbVoTTDLYLcft TOcApCPC+hHHE7tnlSyNsp4wwInyXQLP6y3J11emiWrtl/+zwoT3tvjMDqA3ffViiYt8 Q6pLrF2kKz3K1ZBpEeV+wAMWbKMfH/BVsYeMA6n2O61jSO6oh2pQPE/wpwfglgnjVQpM iGja949Tin0H4NMngIBauTZNqr8kSs/xUUSN5uMj1px79dAMJtM3gxEZoZTOiKE1L745 MlKqN74cK+Toj++BICEPa46l/5QZwz/CJB00CLlxB9KgcswKNGW+4GHfPhHoE78hjXvx UGjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=nm2/jvARW/kXJfePE75YpDEu86GSmMahZJxlHqZ+nOo=; b=g74RqZ0x+uIGryG/TgmqgfXymDFFkWbJ5gVMDU8no11fkM/qgWrvMGMFuDmRLVd5uD C4m2joZMiZPzzJFhBrQffyl8UbBimBTfcXdB1wudN1fec2+obKqIWB1KKtm4XKiDHkA/ MQlKPUl7JHrOoR6KEcNiT2m7kDBAE98X0DPx/vsChf1hBzvMispvR/bVhv8emZM9+DtO iAJaCJDkBdeDPjF4CXliCYpcB3XZ7xEhC7D8e5nFrMyBFcETTGttwBhS33mI8ErNUmvn VYf7FS0wmi7JvwvpSpJ4+jv5sADqR+dCnTIkwSQS0egK6/V2PB1gk3UjMGWQqN7ZSOcL pPbQ== X-Gm-Message-State: AOAM5313oJIOnxiMivgCB7O0NDs8aK6qyX0vEiUvxDQDfcExNd1V+BhY 0wD0Q+frLqySX69O9TGEGOs= X-Google-Smtp-Source: ABdhPJzy0lWj1jz9B5hsbUlW51/H0QmRUmTq9hQ+HA4IeajP1TN0zwbmkeXoGH23N30AGCtu7+iaUA== X-Received: by 2002:a05:6000:1b8a:b0:1e4:b3a3:4c1f with SMTP id r10-20020a0560001b8a00b001e4b3a34c1fmr393552wru.202.1645669430605; Wed, 23 Feb 2022 18:23:50 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id j27sm1164816wrd.32.2022.02.23.18.23.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Feb 2022 18:23:50 -0800 (PST) Content-Language: en-US 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:227553 Archived-At: 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.