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: Wed, 23 Feb 2022 04:21:17 +0200 Message-ID: <300e30e1-aeea-ffa5-fa13-d541ccbffe30@yandex.ru> References: <1de34060-e93b-0a42-fff5-20e283abe0dc@yandex.ru> <2f41ba40-9c3f-ac65-ef0d-300bd11c4867@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40223"; 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 Wed Feb 23 03:23:07 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 1nMhJ4-000ALk-So for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Feb 2022 03:23:07 +0100 Original-Received: from localhost ([::1]:50232 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nMhJ3-0000uf-K5 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 22 Feb 2022 21:23:05 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:49424) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nMhIH-0000od-3A for bug-gnu-emacs@gnu.org; Tue, 22 Feb 2022 21:22:17 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49360) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nMhI2-0005Hp-3j for bug-gnu-emacs@gnu.org; Tue, 22 Feb 2022 21:22:13 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nMhI2-0008Pv-0y for bug-gnu-emacs@gnu.org; Tue, 22 Feb 2022 21:22: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: Wed, 23 Feb 2022 02:22: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.164558289132308 (code B ref 53749); Wed, 23 Feb 2022 02:22:01 +0000 Original-Received: (at 53749) by debbugs.gnu.org; 23 Feb 2022 02:21:31 +0000 Original-Received: from localhost ([127.0.0.1]:43255 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nMhHU-0008Os-6S for submit@debbugs.gnu.org; Tue, 22 Feb 2022 21:21:31 -0500 Original-Received: from mail-wm1-f53.google.com ([209.85.128.53]:39635) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nMhHR-0008Ob-U5 for 53749@debbugs.gnu.org; Tue, 22 Feb 2022 21:21:27 -0500 Original-Received: by mail-wm1-f53.google.com with SMTP id n13-20020a05600c3b8d00b0037bff8a24ebso564532wms.4 for <53749@debbugs.gnu.org>; Tue, 22 Feb 2022 18:21:25 -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=8Aos8TktPPGHjtq06SeU5VGEv5Exji4jZkl/FJ4xc/s=; b=cQeMAiyWM5fCcuITjBEZh9HPx+Kt+cUl1XDxbQRMUsuHmcKvvqG31e/vl7C8hku3TZ BcwvFpvcvs8BFgGX6auiScNwjhemL9z3MDu1ksX9VPpL58dOxwFYwXUuv1jnedk0HzzJ W8WE9++cVb9cGHJbV99jBBhE4q8IcNC7elqooCAdbfZeZDCezU0NZlI92Uu/Y7zquCoM QOJV8G64AhNZLOw/JjyxVOehihg7aVQYmztl7rD3g1Kn/0wu/AWF7CevPbMFf5Y5cZyY M01V6fuAxiIJh+BRZzRJ/fT2Wyna6Lew66/tsAD0AAQodnpMmf9c6u1jDoRrnoeyFA7G owWw== 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=8Aos8TktPPGHjtq06SeU5VGEv5Exji4jZkl/FJ4xc/s=; b=phmFIX57ZFmmeo7vEC2DUn2l7CJMPDQooq5qK2VLmJ+RHaooEYosI1WmLdJHoxjTsD fykvhBv12xBUWCPGk0DZZl8BwMoo3fjlzgcg58F9ra9L2AdCLVcfJhX0dSVCUaBTSzNW 5TTDGjvJlYiuRvJ+pY8TAuQi+1nHG0jgpo+Yd6U+TD8B4RKFU8j4jGE5Q73r5C89Cmns gmH5Gy9MET+O8YYaEl1Qb1hcqERrgwCZFi7AmKelkS+TAWueIpueLfokyPLZWzKl+Y/z pcpWYXmPIRp73hztcN9a2Qh7L22MJOCfXET9qwDHA4s5St4mE+ByW5+HLyv4YV28tYkT 2cnA== X-Gm-Message-State: AOAM532QFBaQXbMGxInoLdEM44bYbjwIoPPiMHHYc4LlwltkFTPpKW3Y 5Pb8XDQvbpdNmEI674Zx+I8= X-Google-Smtp-Source: ABdhPJzW6plc8+eL5irsW6SGpPpntFmvo/8cOfWtVgcMF5TXkH80UdbrKciELezyU2L4S8f/pGeAHQ== X-Received: by 2002:a1c:4c0a:0:b0:37b:b34d:624e with SMTP id z10-20020a1c4c0a000000b0037bb34d624emr5381476wmf.139.1645582879904; Tue, 22 Feb 2022 18:21:19 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id w13sm3233333wrv.21.2022.02.22.18.21.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Feb 2022 18:21:19 -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:227472 Archived-At: Hi David, On 22.02.2022 17:19, David Fussner wrote: > > Do you have a step-by-step scenario? Perhaps using one of the .texi > > manuals already existing in the repo? > > I can't find a good example in the emacs repo, but I'll try to talk > through what happens with a code snippet from biblatex.sty, which I hope > will explain some of the issues we're discussing, even if it is a little > artificial. Thank you. > \DeclareBiblatexOption{global,type}[string]{uniquename}[true]{% >   \ifcsdef{blx@opt@uniquename@#1} >     {\letcs\blx@uniquename{blx@opt@uniquename@#1}} >     {\blx@err@invopt{uniquename=#1}{}}} > \def\blx@opt@uniquename@false{false} > \def\blx@opt@uniquename@init{init} > \def\blx@opt@uniquename@true{full} > \def\blx@opt@uniquename@full{full} > \def\blx@opt@uniquename@allinit{allinit} > \def\blx@opt@uniquename@allfull{allfull} > \def\blx@opt@uniquename@mininit{mininit} > \def\blx@opt@uniquename@minfull{minfull} > > If you do M-? on \ifcsdef{blx@opt@uniquename@#1} using the default > backend, the default search string is blx@opt@uniquename@, and you'll > get two hits, that line and the following one.  Stepping through > xref-references-in-directory shows that the semantic-symref search > (using grep) only finds those two using the :searchtype 'symbol, and > they're returned.  If you change 'symbol to 'regexp, grep finds all the > matches in that code snippet, but then xref--convert-hits uses (format > "\\_<%s\\_>"), which again loses all but the first two hits when it > scans the list provided by grep.  Either grep or emacs here will miss > out on valid hits unless you change both the semantic-symref > instantiation and the format specification. That might call for a different implementation of 'references' indeed. But could you make 'blx@opt@uniquename' the default search string in that example? Does that make sense? 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? > > One way to deal with that is to treat all user inputs as regexps > there. Perhaps some will have to be more verbose that ideal, but as > > long as the user is familiar with the regexp syntax, the behavior > will be both powerful and predictable > > If I understand you right, I think that's what I'm trying to do, but > allowing for users who perhaps aren't too familiar with emacs regexps > and who might typically just accept the default search string offered by > xref. I'm not sure how I feel about the extra "fuzziness" in the behavior which comes with this approach. > >  Could those be disambiguated when the tags are scanned, instead? > Then the user will tailor their input to find the one or the other. > > If I understand you correctly, that's also what I try to do -- each > tagged command in the tags file is searched by the name of the tag, > which in these cases will either start with the escape char or not. > Looking at the biblatex snippet, if you come across > \csuse{blx@opt@uniquename@false} somewhere in a file, and you want to > see what the definition is, you can't know apriori how it was defined, > with \def or with \csdef.  This snippet above mixes both styles, and I > hoped that a user would be allowed to choose whether to search for both > styles without necessarily having to try both forms of the string in > separate searches.  In fact, as the code stands, it only does the second > search if the first one fails, so it still more or less keeps the two > command-naming styles separate. 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. > > Or if we want more fuzzier matching, perhaps creating mode-specific > values of etags-xref-find-definitions-tag-order could help. > > Yeah, you're right, I'm pretty sure I could use a buffer-local value of > that variable to get xref-find-definitions to do the fuzzy matching I'm > after. Does the discussion above at all help to convince you that there > are other issues that might still require a new backend? 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.