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: Wed, 23 Feb 2022 10:45:28 +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="4981"; 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 Wed Feb 23 11:49:57 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 1nMpDY-00014K-0V for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Feb 2022 11:49:56 +0100 Original-Received: from localhost ([::1]:41672 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nMpDW-0001D7-PN for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Feb 2022 05:49:54 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:45208) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nMp9m-0006KM-TR for bug-gnu-emacs@gnu.org; Wed, 23 Feb 2022 05:46:06 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50048) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nMp9m-00022U-JM for bug-gnu-emacs@gnu.org; Wed, 23 Feb 2022 05:46:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nMp9m-0007dl-8Z for bug-gnu-emacs@gnu.org; Wed, 23 Feb 2022 05:46: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: Wed, 23 Feb 2022 10:46: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.164561314929350 (code B ref 53749); Wed, 23 Feb 2022 10:46:02 +0000 Original-Received: (at 53749) by debbugs.gnu.org; 23 Feb 2022 10:45:49 +0000 Original-Received: from localhost ([127.0.0.1]:43945 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nMp9Y-0007dJ-Tp for submit@debbugs.gnu.org; Wed, 23 Feb 2022 05:45:49 -0500 Original-Received: from mail-qv1-f43.google.com ([209.85.219.43]:35328) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nMp9X-0007d6-DI for 53749@debbugs.gnu.org; Wed, 23 Feb 2022 05:45:47 -0500 Original-Received: by mail-qv1-f43.google.com with SMTP id 8so7579558qvf.2 for <53749@debbugs.gnu.org>; Wed, 23 Feb 2022 02:45:47 -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=YpiSIPdTB36nqHxD9dnDiycA9pXb+3/En4b+6fBWfVA=; b=NTcknPRGxBX/O/DzKdmWYFPzXOEuTGH1JlbYNmRoaKVHIwom85O0tDbAULUfw8aiL3 8auWoA95FZT5mV8pGZ7W0QzK7vIdGBS2o3moaGlNBt2i9PgSGfkohkLXAWVWk7cWvOA1 5LQKar4xAjyhnBoIEpkeWpg/nYJipgNwCfgEcfDxjvi341JKYwWdMI1cRKh7FswtxHg7 btiVE7blprxkyHWVcTb0Pb8T/2z5KDIPULaUDy7cuu+4Vu5p8tdgzCz6Og2qv7i3ztKX KEHKRWxaBXLGtB6aYcURoF7qG2qA65VvkNNU/sbgKlZSAnkeYrCvcVlXc7NEg24keasE s/Xw== 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=YpiSIPdTB36nqHxD9dnDiycA9pXb+3/En4b+6fBWfVA=; b=Ei7uercNnAmmfVgmF2F9bTmBPw+kMNm+XtNJVHkYsnPHBZiemBqbRxc4xYnW9tKAEZ n+gP6C84doyQ8fm0PMAnMl+wENILZQjm4u7u0BGbmjsl0qPBnCOEudOZkuBQpK2l1cX/ TubwMgrk/coJUFFkzw3pu4WtmvgJgP6cFKmw5nD4wZxzA5BIulo/SfN28zMB5VkkqZpa KFTDR12vz4KftxfFrcaUFNLvubiHf+L3cHcP2PW1aIXOfYan8loLAXkqWhPTddS6f8PD KVywx8fb7KT+sYmfKO7A8TGPXZKmGATHAZI9nw6ScDutDPOTOYxiT4McKVlJBwARseWg 9oAw== X-Gm-Message-State: AOAM5319nnIi2etYgeRd0W6quZymNqMix2J9mu6/OiGHgR/gpNG1QkXp n0o5v4ZV5RjDldE2UyDNk1sWzuLQeLYvEn1scdHVtCcAWXqGvw== X-Google-Smtp-Source: ABdhPJzidqwhxUO1SHsGSr3s0l4tWNOmz+05CTMCpHq4ceH2L7A0m3WtgJaxisxu24mqbGP7RF72n/NR44HiQZFRG34= X-Received: by 2002:a05:6214:21cf:b0:42d:cc:4121 with SMTP id d15-20020a05621421cf00b0042d00cc4121mr22736020qvh.70.1645613141427; Wed, 23 Feb 2022 02:45:41 -0800 (PST) In-Reply-To: <300e30e1-aeea-ffa5-fa13-d541ccbffe30@yandex.ru> 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:227491 Archived-At: Hi Dmitry, Thanks again for looking at all this, and for your patience. On Wed, 23 Feb 2022 at 02:21, Dmitry Gutov wrote: > > 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? > 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. > 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? > > 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. I see your point here. > > 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. > > 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. David.