GNU bug report logs - #53749
29.0.50; [PATCH] Xref backend for TeX buffers

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: David Fussner <dfussner@HIDDEN>; Keywords: patch moreinfo; dated Thu, 3 Feb 2022 15:10:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 8 Sep 2022 13:39:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 08 09:39:13 2022
Received: from localhost ([127.0.0.1]:57751 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oWHkP-0000KM-5t
	for submit <at> debbugs.gnu.org; Thu, 08 Sep 2022 09:39:13 -0400
Received: from quimby.gnus.org ([95.216.78.240]:57380)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1oWHkN-0000K8-9r
 for 53749 <at> debbugs.gnu.org; Thu, 08 Sep 2022 09:39:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References:
 In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=IOOOhh1kVIe3NDZvnEsWihVh4PoaKhrJdUXVz73wOWc=; b=UkaJzvvbC7h3KPlHBVC6so9RTn
 mvMQkwxtCHnAW3yi2JT2wCGqfCLQB0Tn99eZLM3RQJH830h7A2Sl9hj6Sh94Raj4reJqFNi7DvL2k
 dvCoGysNfHZNfMzz15IIB97TOFdGBFVz04pi9IF8a2z1jhyMOv6Cekrf7Yc5gP05yiHE=;
Received: from [84.212.220.105] (helo=joga)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1oWHkF-0002xX-9t; Thu, 08 Sep 2022 15:39:05 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
To: David Fussner <dfussner@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
In-Reply-To: <CADF+Rtjii7ZHkrfLzS63Yt1UiPPfnOrSsFZe2SMRetOS4w0vng@HIDDEN>
 (David Fussner's message of "Thu, 8 Sep 2022 14:34:47 +0100")
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <1de34060-e93b-0a42-fff5-20e283abe0dc@HIDDEN>
 <87o7vq0zir.fsf@HIDDEN>
 <CADF+Rtjii7ZHkrfLzS63Yt1UiPPfnOrSsFZe2SMRetOS4w0vng@HIDDEN>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj
 SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEWXlWNpalDFzrf/
 //+6G1XXAAAAAWJLR0QDEQxM8gAAAAlwSFlzAAALEgAACxIB0t1+/AAAAAd0SU1FB+YJCAw3Jo99
 xAwAAAEDSURBVCjPbdG9boQwDAfwfxCWKqYghb0duvAUQTqWm5wq3ts36XBT99tvaKWKp6zzBQw1
 QsoPJ8GJgRQGw6aBf0A4QOQPTCLzkTlDdQKmHQbUnwHs0xZd1eC8vg00ok0j3ZgbDIww27nCBu8r
 AJEVrqATrZOogCXHNcO5UWIDmV6PsA4F1jtaLgV9WBiMmmGS0Z+gZRc8SQy+og8SVkWXQDehA9+B
 XlCBaLSyBrH6f99gFFzxPn2INOhQM7ZgTadhh4Ikfr6VDRZ9IkpGQkxj1HJC4ApDd3E75GcwDXCv
 jrRqzPl6490feLPYga9PTA3b9sDku9yfdOEkyN3WL78oXdz+AJswgvt/SGGhAAAAWmVYSWZNTQAq
 AAAACAAFARIAAwAAAAEAAQAAARoABQAAAAEAAABKARsABQAAAAEAAABSASgAAwAAAAEAAgAAAhMA
 AwAAAAEAAQAAAAAAAAAAAEgAAAABAAAASAAAAAEfUvc0AAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIy
 LTA5LTA4VDEyOjU1OjM4KzAwOjAwWNHXXwAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0wOS0wOFQx
 Mjo1NTozOCswMDowMCmMb+MAAAAXdEVYdGV4aWY6WUNiQ3JQb3NpdGlvbmluZwAxrA+AYwAAAABJ
 RU5ErkJggg==
X-Now-Playing: Body =?utf-8?Q?Me=CF=80a's?= _The Work Is Slow_: "Ribbon"
Date: Thu, 08 Sep 2022 15:39:02 +0200
Message-ID: <8735d20yvd.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview: David Fussner <dfussner@HIDDEN> writes: > The
 conclusion
 at the time was that the patch needed reworking before > Dmitry was happy
 with it, and I've not yet found enough time to do so, > though I'm still
 fully intending to make the necessar [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

David Fussner <dfussner@HIDDEN> writes:

> The conclusion at the time was that the patch needed reworking before
> Dmitry was happy with it, and I've not yet found enough time to do so,
> though I'm still fully intending to make the necessary changes. Please
> leave the bug open so I can restart the conversation when I have a
> better patch.

Of course.

> (Oh, and I'm more than happy to sign the copyright
> assignment whenever Dmitry judges the patch to be ready.)

Here's the form to get started:


Please email the following information to assign@HIDDEN, and we
will send you the assignment form for your past and future changes.

Please use your full legal name (in ASCII characters) as the subject
line of the message.
----------------------------------------------------------------------
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]
Emacs

[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]

[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]

[For the copyright registration, what country are you a citizen of?]

[What year were you born?]

[Please write your email address here.]

[Please write your postal address here.]

[Which files have you changed so far, and which new files have you written
so far?]




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 8 Sep 2022 13:35:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 08 09:35:03 2022
Received: from localhost ([127.0.0.1]:57725 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oWHgM-0000CU-Vd
	for submit <at> debbugs.gnu.org; Thu, 08 Sep 2022 09:35:03 -0400
Received: from mail-qt1-f178.google.com ([209.85.160.178]:45025)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dfussner@HIDDEN>) id 1oWHgK-0000Bl-VT
 for 53749 <at> debbugs.gnu.org; Thu, 08 Sep 2022 09:35:01 -0400
Received: by mail-qt1-f178.google.com with SMTP id g14so12812260qto.11
 for <53749 <at> debbugs.gnu.org>; Thu, 08 Sep 2022 06:35:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=googlemail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date;
 bh=GYpXlKyBTaQMnRdBJhetfDcP+G5U5WodofsxJGBSMlk=;
 b=eJ4fAH2Li8G9OWPfLJJ+axl8cWm+52Hbvxs350umlS/DeaEwUtrGViQ44D/bzZqOEr
 O+Bn6+LFCkBFXlNIpztnHN7HMnG2c9UUm15QXiHManYBQLYjCP20TD8Zii/YoyMwcijd
 adSy0bVsB6paRTGkJ2EsuteNgkWxBwQkYxh0jeXInjPeQ19Qm2ZwRaARFM7lYGTKPz+2
 R5cljdVPF47R5wzqzB120lmku+y7ZzAExxCQVVXUndchQ3cRqmj2hsI64LU7l5XKDA8f
 u4KQ3vw/xWARpVhMQu7JAEgs7jL2af2bf1nXX/U9iJLHzoTDxUpokZ7pmMZITzEjx7i4
 EIww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date;
 bh=GYpXlKyBTaQMnRdBJhetfDcP+G5U5WodofsxJGBSMlk=;
 b=oONjOxkqReLXSZMrUPlwH+PBDLPwInXybT8KAt0qjjROZ6KFKwJrNaHSNpegos31Yg
 lulGvwAGhp4jxrXe7hl8W2xuNbpfb5kkB63BthXomnqzD1QZy94Hb9lY4nz6yVYMOcqx
 PpczBPHJ1FIFkdDHjmikZ8kZtWVN7FRL602OcSC0bn2QI8id0/0HEYE7Ro94wOZ31BMX
 rU2TaN+Oeuj/IBwT+fJR0XZearIQLV3kLu64AiqMzCP4EBa6/eNKPFd0zkhtZVmt9yJf
 upBAnaXn3bmG4kkySlja+RedQcvnOtiS40HJ8alhmDx5sgURvrPuUVvYLv+YyIVJGMFQ
 kFEg==
X-Gm-Message-State: ACgBeo3DUKoQTq2cBq4LxSdKn8qe1IFwiYU8UBVR66VIRUMWf3ecf0aO
 7ZYpdsFdLlb9rCO5DIJUcv1GnYy10WkUbf2/TRg=
X-Google-Smtp-Source: AA6agR4XLe8Hwkq95n43He1ciAdk+i6RH3J9rD4Zpl/8h14q5S9PAi9E01EDlYqrM48WgmFXFXjVYDFDDha7QvElvj0=
X-Received: by 2002:ac8:590f:0:b0:343:61fc:e242 with SMTP id
 15-20020ac8590f000000b0034361fce242mr7757191qty.635.1662644095196; Thu, 08
 Sep 2022 06:34:55 -0700 (PDT)
MIME-Version: 1.0
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <1de34060-e93b-0a42-fff5-20e283abe0dc@HIDDEN> <87o7vq0zir.fsf@HIDDEN>
In-Reply-To: <87o7vq0zir.fsf@HIDDEN>
From: David Fussner <dfussner@HIDDEN>
Date: Thu, 8 Sep 2022 14:34:47 +0100
Message-ID: <CADF+Rtjii7ZHkrfLzS63Yt1UiPPfnOrSsFZe2SMRetOS4w0vng@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
To: Lars Ingebrigtsen <larsi@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Lars,

The conclusion at the time was that the patch needed reworking before
Dmitry was happy with it, and I've not yet found enough time to do so,
though I'm still fully intending to make the necessary changes. Please
leave the bug open so I can restart the conversation when I have a
better patch. (Oh, and I'm more than happy to sign the copyright
assignment whenever Dmitry judges the patch to be ready.)

Thanks for the reminder.

David.

On Thu, 8 Sept 2022 at 14:25, Lars Ingebrigtsen <larsi@HIDDEN> wrote:
>
> Dmitry Gutov <dgutov@HIDDEN> writes:
>
> > Let us first discuss whether we could make do without an additional
> > Xref backend. Just to make sure.
>
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> I've only skimmed this bug report, so I might well have missed
> something.  Was there a conclusion here as to what should be done?  It
> looks like useful functionality to me (but it's been years since I've
> written tex-y stuff).
>
> In any case, if this is to be applied, we'd need to have a copyright
> assignment to the FSF on file.  David, would you be willing to sign
> that?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.
Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 8 Sep 2022 13:25:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 08 09:25:14 2022
Received: from localhost ([127.0.0.1]:57682 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oWHWs-0006De-JN
	for submit <at> debbugs.gnu.org; Thu, 08 Sep 2022 09:25:14 -0400
Received: from quimby.gnus.org ([95.216.78.240]:56848)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1oWHWn-0006DK-SY
 for 53749 <at> debbugs.gnu.org; Thu, 08 Sep 2022 09:25:13 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References:
 In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=VqHaHI80aTnlkXeyYytApBLW0GzAO9YKv4fJqHFRH8Y=; b=cZSk5Tr9dDqTVGkxtyYcw4LpSA
 qbICPnDdXkeDJHBeDwAZcUopp0gzgzFLtsssiYr+2tNQsDWvpFGe4+ZvAmdpVpGWPJhxjHj0hHyMN
 1zp++bG+hR9115F7P9G4TmQkWSCTQ0cRzuD48miH1Q3gHabENsGPHp7nMkQ/WY4wy6CQ=;
Received: from [84.212.220.105] (helo=joga)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1oWHWf-0002mJ-4z; Thu, 08 Sep 2022 15:25:03 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
In-Reply-To: <1de34060-e93b-0a42-fff5-20e283abe0dc@HIDDEN> (Dmitry Gutov's
 message of "Mon, 21 Feb 2022 04:11:33 +0200")
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <1de34060-e93b-0a42-fff5-20e283abe0dc@HIDDEN>
X-Now-Playing: Body =?utf-8?Q?Me=CF=80a's?= _The Work Is Slow_: "Rice Tea"
Date: Thu, 08 Sep 2022 15:25:00 +0200
Message-ID: <87o7vq0zir.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview: Dmitry Gutov <dgutov@HIDDEN> writes: > Let us first
 discuss
 whether we could make do without an additional > Xref backend. Just to make
 sure. (I'm going through old bug reports that unfortunately weren't resolved
 at the time.) 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org, David Fussner <dfussner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Dmitry Gutov <dgutov@HIDDEN> writes:

> Let us first discuss whether we could make do without an additional
> Xref backend. Just to make sure.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I've only skimmed this bug report, so I might well have missed
something.  Was there a conclusion here as to what should be done?  It
looks like useful functionality to me (but it's been years since I've
written tex-y stuff).

In any case, if this is to be applied, we'd need to have a copyright
assignment to the FSF on file.  David, would you be willing to sign
that?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 1 Mar 2022 08:46:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 01 03:46:41 2022
Received: from localhost ([127.0.0.1]:35381 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nOy9Z-00012A-Hz
	for submit <at> debbugs.gnu.org; Tue, 01 Mar 2022 03:46:41 -0500
Received: from mail-qk1-f181.google.com ([209.85.222.181]:34748)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dfussner@HIDDEN>) id 1nOy9X-00011y-SE
 for 53749 <at> debbugs.gnu.org; Tue, 01 Mar 2022 03:46:40 -0500
Received: by mail-qk1-f181.google.com with SMTP id 185so12449780qkh.1
 for <53749 <at> debbugs.gnu.org>; Tue, 01 Mar 2022 00:46:39 -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=U9o8mlU0jKv1EIOASU+ECMaswr6voSVvlXxE8L4y1sc=;
 b=h1kMJS6SCBVgk9h+DNgnsBp36saCUrol+H0q53KZLWJCIMkXqReMGteAyMkt5L2dQi
 1ijKJVKwHTdFryAl45BE9wLd6O7bAJ8NapbBWR5J1ZdIKz216R2KNZRaTmGx8bKrJbUP
 S26vtwFhF1MnsXsvuG9vDGv0UeLGxqO0CMvgXGf/YxC8+fcD11ZfyZkVu9sWuEhaCJAh
 fGk0S9DqajQFGdH6G1DkFNYsYFSt6neYfBMZdYluW4Why2l4gIKMXs6ORcqqmSH/xAAM
 O0lHqNd1TTOn/YCeN49iPy0rU7n0ABDqpEJH/kI/eSdT7Mz2/6gBadbq/3aGhGfH7QU0
 qyAQ==
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=U9o8mlU0jKv1EIOASU+ECMaswr6voSVvlXxE8L4y1sc=;
 b=S2hLk1tR4ur2n6xeNiGSYUwoN5U3IsGaHFS7aXYPI/dqdElVwJM82DrZJrN6IZehea
 cADj0n7FfvYNLo9oArIMJ8dZ0cfV2ZI30FgMU/SA4H0/zehDP03M5rFmbGglYpWx4bzK
 cMmCSK9tlh+mhKK2BlPWw3Kf50YPWjYgOqIRjLsjXMPGjzQs9DGQg4uUNJKEIFn1kZuy
 oUYewjKEev4LqHRTjJ54xZoD8JMl577d/Q+EkVzfOb82R8YOBENAvZKNqoGnCb7qEWVE
 tUrj2c6Dg3i0e6gc9AC1kEVqZDwFYVJd+vKfkbPXXHZS3IkN/+yhltXEa2Tfb2WgojtH
 Q14w==
X-Gm-Message-State: AOAM532fdeTwyUN/dLQuldM+OlbVeo3a1uhl4kpvFkYvjpO49Bg5QnGq
 xzApwe/JHBTp/oiZXb4/I7R07WM80qNEGqfYobU=
X-Google-Smtp-Source: ABdhPJzh2tj1HelxrFWXPPxYF5LIW8WVF+/ZgMnkgnolumA+K9nTHFQyiTt9zSoQIuhK5GScHwiW3rbNQWlTWLiNCj8=
X-Received: by 2002:a05:620a:1475:b0:60d:f9d7:a877 with SMTP id
 j21-20020a05620a147500b0060df9d7a877mr13360844qkl.54.1646124394233; Tue, 01
 Mar 2022 00:46:34 -0800 (PST)
MIME-Version: 1.0
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <87pmnad7n3.fsf@HIDDEN>
 <CADF+Rti7JdViHpksyO7cnHy_gj8bCUDkXV0OfAP8Q-CfZn2mkw@HIDDEN>
 <87czj9dhfx.fsf@HIDDEN> <864k4k2lsg.fsf@HIDDEN>
 <CADF+RthbME7D52NMhRRusT=enNQFnJodJ6R1Ak-5ecPg2p3uKw@HIDDEN>
 <86h78j8aur.fsf@HIDDEN> <87sfs39lw6.fsf@HIDDEN> <86a6eaak4d.fsf@HIDDEN>
In-Reply-To: <86a6eaak4d.fsf@HIDDEN>
From: David Fussner <dfussner@HIDDEN>
Date: Tue, 1 Mar 2022 08:46:23 +0000
Message-ID: <CADF+RtieNVUXtZhjSEfyXSx1nbji2=qdVsvaw=PsVh5Hu7p0xA@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
To: Arash Esbati <arash@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org, Augusto Stoffel <arstoffel@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Unless I'm missing something, the in-tree code hasn't (yet) made any
syntax changes for expl3.

Best,

David.

On Mon, 28 Feb 2022 at 19:04, Arash Esbati <arash@HIDDEN> wrote:
>
> Augusto Stoffel <arstoffel@HIDDEN> writes:
>
> > Now, how about expl3 code, where _ and : are letters too?
>
> AUCTeX has a style file expl3.el[1] which changes the syntax for "_" and
> ":".  Can't tell about the builtin tex/latex-mode.
>
> Best, Arash
>
> Footnotes:
> [1]  http://git.savannah.gnu.org/cgit/auctex.git/tree/style/expl3.el




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 28 Feb 2022 19:04:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 28 14:04:37 2022
Received: from localhost ([127.0.0.1]:34783 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nOlK1-0002Ye-FI
	for submit <at> debbugs.gnu.org; Mon, 28 Feb 2022 14:04:37 -0500
Received: from eggs.gnu.org ([209.51.188.92]:55906)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <arash@HIDDEN>) id 1nOlJy-0002YO-Lf
 for 53749 <at> debbugs.gnu.org; Mon, 28 Feb 2022 14:04:35 -0500
Received: from [2001:470:142:3::e] (port=46426 helo=fencepost.gnu.org)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <arash@HIDDEN>)
 id 1nOlJt-0006hH-AC; Mon, 28 Feb 2022 14:04:29 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To:
 From; bh=/RVTOJUrbvpU16z3ul1LDpKuiVm7VTimIijU9TJbNq0=; b=Vp4rpPIV/sJ0f7vXO747
 IwXgJlA+QY+AUEC3aFNLy7Py4wharBdUr0xpdNh1nzc3XYQUyQR/3JnncgVtH+eZKMzcrlzP5D9Z0
 NKI8HE4S+qnZWHmlcS99fn2xLjOKieqWsxDhk0y5faHJTubeja40qz7Ula/F8w6JaLWNrMLdk7Ksz
 avWxvCdc9XJ7dGV8Ro+VSnbDQcFatxxHCW4uUuChk+1X95fQUQWjLKGiGb12PB+rs9OW8YD7nqLWx
 5RS9Ke0ff2XXnLQ10AYDlh9wTdCS0ZYkWdD1ocde5L4wU3q1eVFTmcwKnsHVuEonItChAu2jiGvP1
 UF35kaO60UjUAA==;
Received: from p5b326363.dip0.t-ipconnect.de ([91.50.99.99]:55941 helo=MUTANT)
 by fencepost.gnu.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1)
 (envelope-from <arash@HIDDEN>)
 id 1nOlJs-000493-SK; Mon, 28 Feb 2022 14:04:29 -0500
From: Arash Esbati <arash@HIDDEN>
To: Augusto Stoffel <arstoffel@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <87pmnad7n3.fsf@HIDDEN>
 <CADF+Rti7JdViHpksyO7cnHy_gj8bCUDkXV0OfAP8Q-CfZn2mkw@HIDDEN>
 <87czj9dhfx.fsf@HIDDEN> <864k4k2lsg.fsf@HIDDEN>
 <CADF+RthbME7D52NMhRRusT=enNQFnJodJ6R1Ak-5ecPg2p3uKw@HIDDEN>
 <86h78j8aur.fsf@HIDDEN> <87sfs39lw6.fsf@HIDDEN>
Date: Mon, 28 Feb 2022 20:04:02 +0100
In-Reply-To: <87sfs39lw6.fsf@HIDDEN> (Augusto Stoffel's message of "Mon, 28
 Feb 2022 14:11:05 +0100")
Message-ID: <86a6eaak4d.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org, David Fussner <dfussner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Augusto Stoffel <arstoffel@HIDDEN> writes:

> Now, how about expl3 code, where _ and : are letters too?

AUCTeX has a style file expl3.el[1] which changes the syntax for "_" and
":".  Can't tell about the builtin tex/latex-mode.

Best, Arash

Footnotes:
[1]  http://git.savannah.gnu.org/cgit/auctex.git/tree/style/expl3.el




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 28 Feb 2022 13:11:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 28 08:11:17 2022
Received: from localhost ([127.0.0.1]:60496 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nOfo5-0005L1-Kh
	for submit <at> debbugs.gnu.org; Mon, 28 Feb 2022 08:11:17 -0500
Received: from mail-ej1-f45.google.com ([209.85.218.45]:46950)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <arstoffel@HIDDEN>) id 1nOfo4-0005Km-9z
 for 53749 <at> debbugs.gnu.org; Mon, 28 Feb 2022 08:11:16 -0500
Received: by mail-ej1-f45.google.com with SMTP id qx21so24609175ejb.13
 for <53749 <at> debbugs.gnu.org>; Mon, 28 Feb 2022 05:11:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version;
 bh=PWDq0UhgcV1UsuW1wVTWUXOZmwYlTg0TSLLfpFK9IjM=;
 b=Gm1znBIV8trWlBoZFgiT2dEdpp7QmsIrPrCJS+VZBJXll+bLcmIvT8BqVhVdrYPxlg
 iiCeffhNPqHowOPWfNIJ/+kqlwV+lol3sQF1xcemwTZsLMLA53ZE8vRmb0j57AN+mrQ4
 jUSPxJ1NYoenmQUWmX47UnEMgku/LG+LZvXXUNotUB5WJd5a45i8bC6wvTyADTBNtn0m
 z7LsyECCkCI3/WGQZgwdbJQo+aW8JTlh2F58l56FvOWUSxxyLrgGkaWo7vFHuSVi3yhk
 NXX81D/DvDz/zd/I62tCjcT4c+6I6ryiamqMRZe16MId/5yWM0lGBg4gdacq6H9lVObJ
 qb/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version;
 bh=PWDq0UhgcV1UsuW1wVTWUXOZmwYlTg0TSLLfpFK9IjM=;
 b=surHqNTl+zAF4RD2SMZT2nKIqK7wgCmCrWDQI7xScJZnBWXJ3Zz3DAn0IMeIc/7xV6
 Wd/xEmuTETt5DKpN7s8QMrdmTzfLVuhFuz7G1w+VWZxFrsp2QeIh0McrbZnIR3gIcozP
 2jMgHeVA82xV1XBHDLCOWkm8hvNlA3X73DuDssVdAfE/KkJQpEeDV9lECvTo96ziDuYZ
 cLSMt2Gancc6bV7duUySZGFifsPlC6xD4nLa6Wbo4JcL/PUAdfdFFTQ7SO4V2tdtOHAi
 96Kegzk5z9Mm5lHKmLTG2c33DU5ra90vGFLR1CUqm1NYI1Tky8PolawczFf/O3NZSQDu
 9+UA==
X-Gm-Message-State: AOAM530cvaqNldtYbsgeP0iShTVZew3PYCRrC1DKixbhakRk2K3bEsgf
 81T31vHiCqFmgerDoWqPUNsZWXMYxz1SXw==
X-Google-Smtp-Source: ABdhPJz2P3V4f5/kBDfX04gUN/Va/T5kkxZ12T0wxM+cnw51LzcLV/qnQBcUZH7261yfLu/RQ9tfqA==
X-Received: by 2002:a17:906:407:b0:6cd:472b:2d5f with SMTP id
 d7-20020a170906040700b006cd472b2d5fmr14612566eja.573.1646053866768; 
 Mon, 28 Feb 2022 05:11:06 -0800 (PST)
Received: from ars3 ([2a02:8109:8ac0:56d0::758e])
 by smtp.gmail.com with ESMTPSA id
 w14-20020a509d8e000000b00412cf368b4csm6079917ede.53.2022.02.28.05.11.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 28 Feb 2022 05:11:05 -0800 (PST)
From: Augusto Stoffel <arstoffel@HIDDEN>
To: Arash Esbati <arash@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <87pmnad7n3.fsf@HIDDEN>
 <CADF+Rti7JdViHpksyO7cnHy_gj8bCUDkXV0OfAP8Q-CfZn2mkw@HIDDEN>
 <87czj9dhfx.fsf@HIDDEN> <864k4k2lsg.fsf@HIDDEN>
 <CADF+RthbME7D52NMhRRusT=enNQFnJodJ6R1Ak-5ecPg2p3uKw@HIDDEN>
 <86h78j8aur.fsf@HIDDEN>
Date: Mon, 28 Feb 2022 14:11:05 +0100
In-Reply-To: <86h78j8aur.fsf@HIDDEN> (Arash Esbati's message of "Mon, 28 Feb
 2022 12:54:52 +0100")
Message-ID: <87sfs39lw6.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org, David Fussner <dfussner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On Mon, 28 Feb 2022 at 12:54, Arash Esbati <arash@HIDDEN> wrote:

> Sorry if I'm missing something here, I wasn't tracking this thread.  But
> does doctex-mode (or docTeX in AUCTeX) fit the bill here?

Ah, I forgot about that one.  I mean basically that, but for files like
plain.tex or tikz.code.tex; or also when writing a .sty file directly
for personal purposes only.

But since tex-mode and derived ones always pretend @ is a letter, I
guess there's no real need for a dedicated TeX programming mode.

Now, how about expl3 code, where _ and : are letters too?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 28 Feb 2022 13:05:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 28 08:05:49 2022
Received: from localhost ([127.0.0.1]:60473 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nOfim-0005Af-Fo
	for submit <at> debbugs.gnu.org; Mon, 28 Feb 2022 08:05:48 -0500
Received: from mail-ed1-f42.google.com ([209.85.208.42]:33622)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <arstoffel@HIDDEN>) id 1nOfik-0005AR-E2
 for 53749 <at> debbugs.gnu.org; Mon, 28 Feb 2022 08:05:46 -0500
Received: by mail-ed1-f42.google.com with SMTP id s14so17549440edw.0
 for <53749 <at> debbugs.gnu.org>; Mon, 28 Feb 2022 05:05:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=49H0wRYpOluU+MRv3P538YcwV03c6qfYnHcDghI3il4=;
 b=oOAvMH5kT4KT36vpFPIaCM4fgdZxuCbJR4r1TpW3k1lvEv0NZgkQ59N/dLLPvqFi3q
 WvTrwDveDRgU5oP24bsprqZwY/GthYSHNTHWYym6PNL2V0tmfmuKWUFuu4n1OExn/8rT
 fNMxEL8bENZ68AuRO9P0CW/ADJYa5svijSsAq/2ROcwMvvHqEiqL0QZ/vAnBuHidLlUO
 A8lkDp5t7qDsnmK/X4qzbPVu561P3MEfUZ72g7URZpRBha/VlHDFv9SX5UgQFz7ieXpu
 EecObhuRR5bglfF9cjR0OFolXjta55cg3BNjy62k99UZn/5W/lFcycAvMBVIG5ICuIqN
 u1xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version:content-transfer-encoding;
 bh=49H0wRYpOluU+MRv3P538YcwV03c6qfYnHcDghI3il4=;
 b=gOSe8z7gRO+f2wKZfww2iGLN91LpMWWqpXGOREvxAWKukJRcNsHWom+7NBB5r3JKVF
 2CuqNq0l03I9g94aK2GQUn0MSC33cD2PTqag27cpxUm4QYEbGXZmsLaDcG4p+yPbi6fC
 dKJsiOPp0jK7YIcURJTPkmxw3oWYZ7dI0LYxczXg3GfK9uzM95m0+zlZ+pg/DR/tofpv
 txnN77WvFu7Bej6L62tLwnUWsl2Wp3DxQfvRJGQa7cG9woXXNHSW8g3+7KhFoZ/jct1d
 D68bG7II0iaECqOX3mUU0zJsrnkusw5SKufVC6PxxUSGzklTn1djxOJ41k5VBc1ee0+F
 xZ4Q==
X-Gm-Message-State: AOAM532oofOfSBdP2biTnORR6l3sY44Adsh3kRfMR3t2MlzUljaOo0Oc
 tveqbwoHy3gsPjphneFBlD0OAYfRMm8MvA==
X-Google-Smtp-Source: ABdhPJy8qwtmp3aZ8OSqQcuiBKcz7ODAO1FIRzEYdsyhfBUS3VoCGvQ91GkfJ7NiyS+e1uqeiRyr+Q==
X-Received: by 2002:aa7:c0ce:0:b0:400:1a:e9a2 with SMTP id
 j14-20020aa7c0ce000000b00400001ae9a2mr19883158edp.396.1646053540320; 
 Mon, 28 Feb 2022 05:05:40 -0800 (PST)
Received: from ars3 ([2a02:8109:8ac0:56d0::758e])
 by smtp.gmail.com with ESMTPSA id
 sb31-20020a1709076d9f00b006ceb969822esm4385682ejc.76.2022.02.28.05.05.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 28 Feb 2022 05:05:39 -0800 (PST)
From: Augusto Stoffel <arstoffel@HIDDEN>
To: David Fussner <dfussner@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <87pmnad7n3.fsf@HIDDEN>
 <CADF+Rti7JdViHpksyO7cnHy_gj8bCUDkXV0OfAP8Q-CfZn2mkw@HIDDEN>
 <87czj9dhfx.fsf@HIDDEN> <864k4k2lsg.fsf@HIDDEN>
 <CADF+RthbME7D52NMhRRusT=enNQFnJodJ6R1Ak-5ecPg2p3uKw@HIDDEN>
Date: Mon, 28 Feb 2022 14:05:38 +0100
In-Reply-To: <CADF+RthbME7D52NMhRRusT=enNQFnJodJ6R1Ak-5ecPg2p3uKw@HIDDEN>
 (David Fussner's message of "Mon, 28 Feb 2022 09:09:36 +0000")
Message-ID: <87wnhf9m59.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org, Arash Esbati <arash@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On Mon, 28 Feb 2022 at 09:09, David Fussner <dfussner@HIDDEN> wrote:

> For what it's worth, I've always just done what Arash suggests when
> RefTeX gets out of sync, and haven't had any issues with it that I can
> remember.  (To be fair, my use cases haven't exactly been exotic.)

Sure, I'm aware you have to do the manual resync when using RefTeX.  I
just think it's a totally unnecessary hurdle at this time and age.  I
used to advice the RefTeX commands so they would reparse the document
every time, and this worked just fine.  (Granted, I never worked on
anything over 100 pages or so, but it should also be possible to reparse
individual files of a multifile project so that the file sizes never
become an issue.)

>> The problem is that there's no way for Emacs to communicate that one of
>> these programming modes is to be used.  This could be fixed in two ways:
>>
>> A. by creating latex-prog and latex-expl3 derived modes in Emacs, or
>>
>> B. adding heuristics to Digestif to decide if a given file is "document"
>>    or "code".
>>
>> Do you have any thoughts about A?  Would there be any other benefits in
>> Emacs to justify the latex-prog and latex-expl3 major modes?  It seems
>> that (at least in AUCTeX) @ is always considered a letter, which may be
>> innocuous but is kinda wrong.
>
> The only thought I have is that it sounds like a new major mode would
> be overkill for what you need here.  I would think that a variable or
> defcustom might do the trick, or at most maybe a minor mode?  When
> navigating code I really want to be able to follow the commands to
> their source no matter whether the command is internal or for users,
> though I can see how in a code-completion setting you might want to be
> able to separate the two more cleanly.  Obviously, I'm not the person
> you need to convince about all of this -- that would be Arash and the
> emacs maintainers, themselves.

Okay, thanks for your insight.

>
> Best,
>
> David.
>
> On Sun, 27 Feb 2022 at 18:43, Arash Esbati <arash@HIDDEN> wrote:
>>
>> Augusto Stoffel <arstoffel@HIDDEN> writes:
>>
>> > If you type \label{something}, as opposed to using the RefTeX command
>> > to add a label (or if you edit the label by hand) then RefTeX will not
>> > reparse the document and get out of sync.
>>
>> If you know the known labels to RefTeX are out of sync, you can issue
>> `C-c )' with a prefix argument:
>>
>> ,----[ C-h f reftex-reference RET ]
>> | reftex-reference is an interactive native compiled Lisp function in
>> | =E2=80=98reftex-ref.el=E2=80=99.
>> |
>> | (reftex-reference &optional TYPE NO-INSERT CUT)
>> |
>> | Make a LaTeX reference.  Look only for labels of a certain TYPE.
>> | With prefix arg, force to rescan buffer for labels.  This should only =
be
>> | necessary if you have recently entered labels yourself without using
>> | reftex-label.  Rescanning of the buffer can also be requested from the
>> | label selection menu.
>> | The function returns the selected label or nil.
>> | If NO-INSERT is non-nil, do not insert \ref command, just return label.
>> | When called with 2 C-u prefix args, disable magic word recognition.
>> |
>> |   Probably introduced at or before Emacs version 20.1.
>> |
>> `----
>>
>> Or in the labels *RefTeX select* buffer, you have these choices:
>>
>>  r / C-u r  Reparse document / Reparse entire document.
>>
>> I usually hit r when I don't find the label I'm looking for.
>>
>> > Or at least that was the case when I still used RefTeX.  So it might
>> > be worth considering some cache invalidation scheme there.
>>
>> The question is if it's worth the effort where a remedy is already in
>> place.
>>
>> Best, Arash




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 28 Feb 2022 11:55:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 28 06:55:33 2022
Received: from localhost ([127.0.0.1]:60322 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nOecn-00012D-HD
	for submit <at> debbugs.gnu.org; Mon, 28 Feb 2022 06:55:33 -0500
Received: from eggs.gnu.org ([209.51.188.92]:57192)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <arash@HIDDEN>) id 1nOecl-000121-MK
 for 53749 <at> debbugs.gnu.org; Mon, 28 Feb 2022 06:55:32 -0500
Received: from [2001:470:142:3::e] (port=37644 helo=fencepost.gnu.org)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <arash@HIDDEN>)
 id 1nOecg-0001z2-C9; Mon, 28 Feb 2022 06:55:26 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To:
 From; bh=cqn9p5eHNJByoXorGwu720L6kgXeZR7ZMokcRcx2SNk=; b=MbzMNddh1vOuF+p01xLB
 ER9r3rVpqIp1O4sPbONZSzJqzFsApAhslgqhqpv13q4DhyUyTtssx01dawokZjKOvHntbRAWK1Vz5
 QuMQrrrJRL5wJ+c/qNKRJby4ENe7soptkCX/85H7X31o3+V+kcSiSTsgcyoSKM9OYLQhT0qoWel5K
 6P6MlhpaS/4HsC3gwk9dd58ZKvFqUO5ImSXRH0npZC/I6XPYZzgJTrUc/fIf1Q/z73mY7AJt8Ljg1
 +ozr4jkv+hO1sUUhVVUgD+YG+PHe2+ZjOoVkPkvw4PvdGHgarD+WoDUuQSgNugqYUZvSnPI/nQW2D
 vK2dV9x0rwdVHw==;
Received: from p5b326363.dip0.t-ipconnect.de ([91.50.99.99]:59179 helo=MUTANT)
 by fencepost.gnu.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1)
 (envelope-from <arash@HIDDEN>)
 id 1nOecf-0003CL-Rc; Mon, 28 Feb 2022 06:55:26 -0500
From: Arash Esbati <arash@HIDDEN>
To: David Fussner <dfussner@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <87pmnad7n3.fsf@HIDDEN>
 <CADF+Rti7JdViHpksyO7cnHy_gj8bCUDkXV0OfAP8Q-CfZn2mkw@HIDDEN>
 <87czj9dhfx.fsf@HIDDEN> <864k4k2lsg.fsf@HIDDEN>
 <CADF+RthbME7D52NMhRRusT=enNQFnJodJ6R1Ak-5ecPg2p3uKw@HIDDEN>
Date: Mon, 28 Feb 2022 12:54:52 +0100
In-Reply-To: <CADF+RthbME7D52NMhRRusT=enNQFnJodJ6R1Ak-5ecPg2p3uKw@HIDDEN>
 (David Fussner's message of "Mon, 28 Feb 2022 09:09:36 +0000")
Message-ID: <86h78j8aur.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org, Augusto Stoffel <arstoffel@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

David Fussner <dfussner@HIDDEN> writes:

>> The problem is that there's no way for Emacs to communicate that one of
>> these programming modes is to be used.  This could be fixed in two ways:
>>
>> A. by creating latex-prog and latex-expl3 derived modes in Emacs, or
>>
>> B. adding heuristics to Digestif to decide if a given file is "document"
>>    or "code".
>>
>> Do you have any thoughts about A?  Would there be any other benefits in
>> Emacs to justify the latex-prog and latex-expl3 major modes?  It seems
>> that (at least in AUCTeX) @ is always considered a letter, which may be
>> innocuous but is kinda wrong.
>
> The only thought I have is that it sounds like a new major mode would
> be overkill for what you need here.  I would think that a variable or
> defcustom might do the trick, or at most maybe a minor mode?

Sorry if I'm missing something here, I wasn't tracking this thread.  But
does doctex-mode (or docTeX in AUCTeX) fit the bill here?

Best, Arash




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 28 Feb 2022 09:09:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 28 04:09:57 2022
Received: from localhost ([127.0.0.1]:59985 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nOc2X-0002JA-1w
	for submit <at> debbugs.gnu.org; Mon, 28 Feb 2022 04:09:57 -0500
Received: from mail-qt1-f176.google.com ([209.85.160.176]:40794)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dfussner@HIDDEN>) id 1nOc2T-0002Ix-FE
 for 53749 <at> debbugs.gnu.org; Mon, 28 Feb 2022 04:09:53 -0500
Received: by mail-qt1-f176.google.com with SMTP id t28so8342027qtc.7
 for <53749 <at> debbugs.gnu.org>; Mon, 28 Feb 2022 01:09:53 -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:content-transfer-encoding;
 bh=TEcTYdBXf7Uh+Wy/k7NnKvcCPiO55Hmrfl2PGCNGXis=;
 b=EFVxelue7r/2JiIoDN2nRNtF0fX/8yv5x+sHhSZH1uJloltvz1qpb/bNzMr335byC+
 /hiJh8Q5qbxGBPAETU42e3mvhAM7kyiGCU86q/PJXwuBvt3IaB9Rcd69ImYiK4PPqqVR
 kjfiNiZoz4xOPz7DpSNsFzGsFIi7Mw5Iim2Z3n9T8+O97RAMV756BQz6s9JonZrDhDY6
 MF4vukrOeQugHPBIW7waUxbc6GdSbO65Fv3NUnpf+jsO2pU+49WAkhG1Dw4bi5XxkLvh
 urWxKxyIa4ZohsL2UOJXQK4R4WGWyVbF6gVhQcxGbS7km4ofnKg7t7ynuAwRvvxnDLjd
 o9fA==
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:content-transfer-encoding;
 bh=TEcTYdBXf7Uh+Wy/k7NnKvcCPiO55Hmrfl2PGCNGXis=;
 b=3K8GCJfoDpzMZxgjAzVOdKEpgevu+Z5UuJwSgESB77d3FzCvomID57bHW/NYywHEJm
 CnkNWUJ3HI2Vm+kxeC9nYTiN2WXX18oXQZ/SD53uuMHZcZh4xR8CNNeIC7oY5Wgsv9da
 ntjmVXNOIOORmk0oDoLPjgDIrLQAIKviji6nrYs6BmuvDJRf1TqNSkSewtpuFO5TAasu
 zDFfJdVrIbMB2RP3C+4HC++iVarWvpNUJVHt+25h4SClJ8TnLV3kVDaDf/JnxclgISpN
 fUwjcwnQcngp6hteJpdRGpQZKAplcHX9eiTpxpPbllyzpYwZkWsZEbXInRgnjZZ9nwSP
 DwPA==
X-Gm-Message-State: AOAM532tI4vMZHqTzsU6E+eWdW9e4z49rAiNpFcmoVFYDxndKOr1PMhp
 mO600YidFldzMb1iWShIug/FZgA4X/kbHNXlURc=
X-Google-Smtp-Source: ABdhPJzYk8EWMj294pfJCKOolNqIrTUGsI1TQiBv+CBH1ze0cBX4POxLrQ6AierbvFC01xJqV9qxM/xYwpgL+RRrTl8=
X-Received: by 2002:a05:622a:1a1c:b0:2de:82f:b1f5 with SMTP id
 f28-20020a05622a1a1c00b002de082fb1f5mr15895498qtb.156.1646039387910; Mon, 28
 Feb 2022 01:09:47 -0800 (PST)
MIME-Version: 1.0
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <87pmnad7n3.fsf@HIDDEN>
 <CADF+Rti7JdViHpksyO7cnHy_gj8bCUDkXV0OfAP8Q-CfZn2mkw@HIDDEN>
 <87czj9dhfx.fsf@HIDDEN> <864k4k2lsg.fsf@HIDDEN>
In-Reply-To: <864k4k2lsg.fsf@HIDDEN>
From: David Fussner <dfussner@HIDDEN>
Date: Mon, 28 Feb 2022 09:09:36 +0000
Message-ID: <CADF+RthbME7D52NMhRRusT=enNQFnJodJ6R1Ak-5ecPg2p3uKw@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
To: Arash Esbati <arash@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org, Augusto Stoffel <arstoffel@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Augusto,

For what it's worth, I've always just done what Arash suggests when
RefTeX gets out of sync, and haven't had any issues with it that I can
remember.  (To be fair, my use cases haven't exactly been exotic.)

> The problem is that there's no way for Emacs to communicate that one of
> these programming modes is to be used.  This could be fixed in two ways:
>
> A. by creating latex-prog and latex-expl3 derived modes in Emacs, or
>
> B. adding heuristics to Digestif to decide if a given file is "document"
>    or "code".
>
> Do you have any thoughts about A?  Would there be any other benefits in
> Emacs to justify the latex-prog and latex-expl3 major modes?  It seems
> that (at least in AUCTeX) @ is always considered a letter, which may be
> innocuous but is kinda wrong.

The only thought I have is that it sounds like a new major mode would
be overkill for what you need here.  I would think that a variable or
defcustom might do the trick, or at most maybe a minor mode?  When
navigating code I really want to be able to follow the commands to
their source no matter whether the command is internal or for users,
though I can see how in a code-completion setting you might want to be
able to separate the two more cleanly.  Obviously, I'm not the person
you need to convince about all of this -- that would be Arash and the
emacs maintainers, themselves.

Best,

David.

On Sun, 27 Feb 2022 at 18:43, Arash Esbati <arash@HIDDEN> wrote:
>
> Augusto Stoffel <arstoffel@HIDDEN> writes:
>
> > If you type \label{something}, as opposed to using the RefTeX command
> > to add a label (or if you edit the label by hand) then RefTeX will not
> > reparse the document and get out of sync.
>
> If you know the known labels to RefTeX are out of sync, you can issue
> `C-c )' with a prefix argument:
>
> ,----[ C-h f reftex-reference RET ]
> | reftex-reference is an interactive native compiled Lisp function in
> | =E2=80=98reftex-ref.el=E2=80=99.
> |
> | (reftex-reference &optional TYPE NO-INSERT CUT)
> |
> | Make a LaTeX reference.  Look only for labels of a certain TYPE.
> | With prefix arg, force to rescan buffer for labels.  This should only b=
e
> | necessary if you have recently entered labels yourself without using
> | reftex-label.  Rescanning of the buffer can also be requested from the
> | label selection menu.
> | The function returns the selected label or nil.
> | If NO-INSERT is non-nil, do not insert \ref command, just return label.
> | When called with 2 C-u prefix args, disable magic word recognition.
> |
> |   Probably introduced at or before Emacs version 20.1.
> |
> `----
>
> Or in the labels *RefTeX select* buffer, you have these choices:
>
>  r / C-u r  Reparse document / Reparse entire document.
>
> I usually hit r when I don't find the label I'm looking for.
>
> > Or at least that was the case when I still used RefTeX.  So it might
> > be worth considering some cache invalidation scheme there.
>
> The question is if it's worth the effort where a remedy is already in
> place.
>
> Best, Arash




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 27 Feb 2022 18:43:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 27 13:43:17 2022
Received: from localhost ([127.0.0.1]:59207 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nOOVo-00048t-Vp
	for submit <at> debbugs.gnu.org; Sun, 27 Feb 2022 13:43:17 -0500
Received: from eggs.gnu.org ([209.51.188.92]:59644)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <arash@HIDDEN>) id 1nOOVn-00048g-9t
 for 53749 <at> debbugs.gnu.org; Sun, 27 Feb 2022 13:43:15 -0500
Received: from [2001:470:142:3::e] (port=54422 helo=fencepost.gnu.org)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <arash@HIDDEN>)
 id 1nOOVh-0007MC-2h; Sun, 27 Feb 2022 13:43:09 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To:
 From; bh=sL/+jcbohWc/odqt66v0yqvRuyvd36sR/FDyPGjtQ/0=; b=i+dHj06LfboVDCJheM2d
 psR/ZPC8owPRXUJ+Opek/b5eDKcudj2tTapC7Mrvz8HFS7L3JXTSVS1cxbOxWJ8+FnQ+68BGYcZBi
 oMn8dH09n3Ii48soAEPOYj8UIPP0GHYg+PKGnEV/BJL/zn1ejrR1+WoNAdt/5HXViYUul20WT/nRg
 q3MEE2qgGEUFFKokgQtKgkJDg91YHKG096Jo/3i0UvIwldyW6GDF5ZovTgj3K1ArO6KFt/sWM/+7P
 vdenpxJ2T/bgusyr3/X9grT+VKktrLAOa2GE8zPYSPDkvd6S/OAK3t5qzj6bctrTD6v/LJrbE9BLh
 jX7yYWOsDCwJgA==;
Received: from p5b326363.dip0.t-ipconnect.de ([91.50.99.99]:50422 helo=MUTANT)
 by fencepost.gnu.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1)
 (envelope-from <arash@HIDDEN>)
 id 1nOOVg-00006d-B8; Sun, 27 Feb 2022 13:43:08 -0500
From: Arash Esbati <arash@HIDDEN>
To: Augusto Stoffel <arstoffel@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <87pmnad7n3.fsf@HIDDEN>
 <CADF+Rti7JdViHpksyO7cnHy_gj8bCUDkXV0OfAP8Q-CfZn2mkw@HIDDEN>
 <87czj9dhfx.fsf@HIDDEN>
Date: Sun, 27 Feb 2022 19:42:55 +0100
In-Reply-To: <87czj9dhfx.fsf@HIDDEN> (Augusto Stoffel's message of "Sat, 26
 Feb 2022 11:56:50 +0100")
Message-ID: <864k4k2lsg.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org, David Fussner <dfussner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Augusto Stoffel <arstoffel@HIDDEN> writes:

> If you type \label{something}, as opposed to using the RefTeX command
> to add a label (or if you edit the label by hand) then RefTeX will not
> reparse the document and get out of sync.

If you know the known labels to RefTeX are out of sync, you can issue
`C-c )' with a prefix argument:

,----[ C-h f reftex-reference RET ]
| reftex-reference is an interactive native compiled Lisp function in
| =E2=80=98reftex-ref.el=E2=80=99.
|=20
| (reftex-reference &optional TYPE NO-INSERT CUT)
|=20
| Make a LaTeX reference.  Look only for labels of a certain TYPE.
| With prefix arg, force to rescan buffer for labels.  This should only be
| necessary if you have recently entered labels yourself without using
| reftex-label.  Rescanning of the buffer can also be requested from the
| label selection menu.
| The function returns the selected label or nil.
| If NO-INSERT is non-nil, do not insert \ref command, just return label.
| When called with 2 C-u prefix args, disable magic word recognition.
|=20
|   Probably introduced at or before Emacs version 20.1.
|=20
`----

Or in the labels *RefTeX select* buffer, you have these choices:

 r / C-u r  Reparse document / Reparse entire document.

I usually hit r when I don't find the label I'm looking for.

> Or at least that was the case when I still used RefTeX.  So it might
> be worth considering some cache invalidation scheme there.

The question is if it's worth the effort where a remedy is already in
place.

Best, Arash




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 26 Feb 2022 10:57:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 26 05:57:07 2022
Received: from localhost ([127.0.0.1]:54337 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nNul9-00084W-H4
	for submit <at> debbugs.gnu.org; Sat, 26 Feb 2022 05:57:07 -0500
Received: from mail-ed1-f41.google.com ([209.85.208.41]:45801)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <arstoffel@HIDDEN>) id 1nNul0-00083T-Dr
 for 53749 <at> debbugs.gnu.org; Sat, 26 Feb 2022 05:56:58 -0500
Received: by mail-ed1-f41.google.com with SMTP id c6so10668571edk.12
 for <53749 <at> debbugs.gnu.org>; Sat, 26 Feb 2022 02:56:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version;
 bh=FiuLSzPgHom99UkqJzF7iOp8PIqjGYHi7APrz9WKkqA=;
 b=f6RY2WEltd8BdP+oHStF6LtZ6WrYeruvkeoyxKO/BUOYZY55UHnzyV/UATvO4brgLa
 R3OkhPX8+lXxXI1NCR+FbuB2K3KEnqUgDwIDwP9mBAkAM+JLLIlwpAGWMlhipc3d+DQY
 5WcjfMxSPNEkIgNGxsnmezVFFGUlo9gfJF/HvPXvtqm557mXCArPMb/E43W8dK6OebZX
 vdp3m7q/DJUR9EvgJCqqTnK470PAEirDXsv0QQml4XfB7Yy6UqQTbdDtgTc6mi3cp+rP
 9X6qq4MgtEiOeCOm0FxyJPMtKtmcSDSWzhtkVv4U0b9SjmPjuEWdWtxxyFSvatchQ1Hz
 Hhcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version;
 bh=FiuLSzPgHom99UkqJzF7iOp8PIqjGYHi7APrz9WKkqA=;
 b=vduFUamzPXRGaTjvUmD93FZVafTv8jUTrUBSbQQmFYNA9qYMpekHh6ZveXSYDmsbIp
 LdJ8R0XhXQC2CDoMT1ky1rnwmaTdy125htwSGSLkd8PgbTI1iHmAMb38dECgpv5dslgM
 zjS17+ly89vW5WVt5NnmprCjypg0xprAQboBT/FsNHpsxs/ve9sKllBM19cH9bACyNp/
 B/9rhH/8nuMekG9obAbWeRILwmakMmwRdohSgdgKKkoXrcSPem230IMX/SRBXxFJPYE6
 +hHbPW/3BZqSHc7PafSNGqMQXsQIrHmQIjncMfZPLDbQyz6WoyYQbr88YwjxqQ274EPx
 2NTg==
X-Gm-Message-State: AOAM530xuApXiqqS0lb1dUsf2dEP1aVXlKzQ2/w4gUjZAkxWEDMGg86C
 n8uzjblisV2hOOmJ2nSFjJgcQ0SdNkwOdw==
X-Google-Smtp-Source: ABdhPJyto6oGJpRqyfOM7aocdnKqMYaReM6+HGONklHUYzjPh4qQb/sycpqQ+ua+FjYpfEhmssmmmg==
X-Received: by 2002:a50:aa8c:0:b0:410:801c:4e2f with SMTP id
 q12-20020a50aa8c000000b00410801c4e2fmr10752783edc.179.1645873012160; 
 Sat, 26 Feb 2022 02:56:52 -0800 (PST)
Received: from ars3 ([2a02:8109:8ac0:56d0::758e])
 by smtp.gmail.com with ESMTPSA id
 o14-20020a170906774e00b006d5b915f27dsm2086897ejn.169.2022.02.26.02.56.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 26 Feb 2022 02:56:51 -0800 (PST)
From: Augusto Stoffel <arstoffel@HIDDEN>
To: David Fussner <dfussner@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <87pmnad7n3.fsf@HIDDEN>
 <CADF+Rti7JdViHpksyO7cnHy_gj8bCUDkXV0OfAP8Q-CfZn2mkw@HIDDEN>
Date: Sat, 26 Feb 2022 11:56:50 +0100
In-Reply-To: <CADF+Rti7JdViHpksyO7cnHy_gj8bCUDkXV0OfAP8Q-CfZn2mkw@HIDDEN>
 (David Fussner's message of "Sat, 26 Feb 2022 09:29:06 +0000")
Message-ID: <87czj9dhfx.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org, "David Fussner via Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On Sat, 26 Feb 2022 at 09:29, David Fussner <dfussner@HIDDEN> wrote:

> Hi Augusto,
>
> On Fri, 25 Feb 2022 at 20:16, Augusto Stoffel <arstoffel@HIDDEN> wrote:
>>
>> Hi David,
>
>>
>> I took a superficial look at this thread, and this seems very nice.
>
> Thanks!
>
>>
>> I was wondering why you want to be able to find the definition of macros
>> with @ in their name.  Those are "private" macros that the user
>> shouldn't have occasion to use.  Is it for a TeX programmer mode?
>
> I confess that TeX developers are indeed one of the main targets for
> the feature as I envisioned it.  For creating and following \labels,
> \refs, and \cites (of all sorts) I find RefTeX very handy, as well as
> for jumping around \chapters and \sections and the like.  What I miss
> when developing are the code-navigation features of something like
> xref, which are (from the user point of view) both simple and
> powerful.  My modest goal was to make Emacs' extensive infrastructure
> work a little better out of the box for TeX documents, especially for
> styles and other collections of macros.

Sorry for entering a tangent, but here's one more thing I dislike about
RefTeX you might want to consider.  If you type \label{something}, as
opposed to using the RefTeX command to add a label (or if you edit the
label by hand) then RefTeX will not reparse the document and get out of
sync.  Or at least that was the case when I still used RefTeX.  So it
might be worth considering some cache invalidation scheme there.
(Digestif has caching for multifile documents, but parsing a single file
is fast enough that this is not a problem I need to worry :-).)

>>
>> Let me also mention a library I wrote for analyzing TeX code (accessible
>> to Emacs via LSP):
>>
>>     https://github.com/astoff/digestif
>>
>> It's written in Lua (can run on the LuaTeX interpreter) and uses PEGs
>> for flexible parsing.  If you want to be very ambitious about what you
>> are able to parse, I think regexps are not sufficient.
>>
>> Digestif can handle \cite{messed up reference} just fine, for example.
>>
>
> This looks very nice indeed, and if I'm reading it right provides a
> replacement both for RefTeX and for the code-navigation features I'm
> trying to implement.

That's right.  Also command completion (including snippets, if that's
your thing) and Eldoc.

>  I figure I'll continue trying to get improved
> out-of-the-box features into core, and if I manage to satisfy Dmitry
> we'll then have a choice, but in any case I'm going to have a longer
> look at digestif when I get some time.

Let me mention one last thing, since you seem interested in a TeX
programming mode.

Digestif will not work great out of the box for programming because it
correctly considers @ to have catcode "other" (so it can't be part of
the name of a command).  But this is trivial to change and, in fact,
Digestif already has a "latex-prog" mode that simulates the correct
catcodes.  It would be easy to include a "latex-expl3" mode as well.

The problem is that there's no way for Emacs to communicate that one of
these programming modes is to be used.  This could be fixed in two ways:

A. by creating latex-prog and latex-expl3 derived modes in Emacs, or

B. adding heuristics to Digestif to decide if a given file is "document"
   or "code".

Do you have any thoughts about A?  Would there be any other benefits in
Emacs to justify the latex-prog and latex-expl3 major modes?  It seems
that (at least in AUCTeX) @ is always considered a letter, which may be
innocuous but is kinda wrong.

>
> Thanks for the hint!
>
> David.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 26 Feb 2022 10:56:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 26 05:56:59 2022
Received: from localhost ([127.0.0.1]:54334 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nNul1-00083m-49
	for submit <at> debbugs.gnu.org; Sat, 26 Feb 2022 05:56:59 -0500
Received: from lists.gnu.org ([209.51.188.17]:38498)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <arstoffel@HIDDEN>) id 1nNuky-00083X-QT
 for submit <at> debbugs.gnu.org; Sat, 26 Feb 2022 05:56:57 -0500
Received: from eggs.gnu.org ([209.51.188.92]:53568)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <arstoffel@HIDDEN>)
 id 1nNuky-0002LK-Iw
 for bug-gnu-emacs@HIDDEN; Sat, 26 Feb 2022 05:56:56 -0500
Received: from [2a00:1450:4864:20::532] (port=39593
 helo=mail-ed1-x532.google.com)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <arstoffel@HIDDEN>)
 id 1nNukw-0008Cv-Eq
 for bug-gnu-emacs@HIDDEN; Sat, 26 Feb 2022 05:56:56 -0500
Received: by mail-ed1-x532.google.com with SMTP id g20so10714243edw.6
 for <bug-gnu-emacs@HIDDEN>; Sat, 26 Feb 2022 02:56:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version;
 bh=FiuLSzPgHom99UkqJzF7iOp8PIqjGYHi7APrz9WKkqA=;
 b=f6RY2WEltd8BdP+oHStF6LtZ6WrYeruvkeoyxKO/BUOYZY55UHnzyV/UATvO4brgLa
 R3OkhPX8+lXxXI1NCR+FbuB2K3KEnqUgDwIDwP9mBAkAM+JLLIlwpAGWMlhipc3d+DQY
 5WcjfMxSPNEkIgNGxsnmezVFFGUlo9gfJF/HvPXvtqm557mXCArPMb/E43W8dK6OebZX
 vdp3m7q/DJUR9EvgJCqqTnK470PAEirDXsv0QQml4XfB7Yy6UqQTbdDtgTc6mi3cp+rP
 9X6qq4MgtEiOeCOm0FxyJPMtKtmcSDSWzhtkVv4U0b9SjmPjuEWdWtxxyFSvatchQ1Hz
 Hhcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version;
 bh=FiuLSzPgHom99UkqJzF7iOp8PIqjGYHi7APrz9WKkqA=;
 b=UcdCvNGM4O5i+dH8DJIF59zcHANmJoA+cMnM3eD+vGDnFZc0n+FqDohU6bcp742C6N
 v+K0TwYRj+GrK5NduQyZbbpwdBreuUEH4UL3zqZRToAgbJfAhGjpyaoUoUv3OL7xyAsX
 pX0l1fOOFWBnDfmP1/0Iny7wJNTOy52hiozf3CxERq7tGjWmDjSCGh9MpXmyi8fpENle
 1CoVIknCOnU9k2FAO0l5d1slO4DYM/4Cgvdo9MmtCJEYYsvjhIPOt5bChb5cduBEeayW
 dLQPYvZ/TTfnIhmuN1Y25bAyovamg8pKQsPEd8sQRz2ICHhLPGL5OP9t3gpvDoIwTjUp
 3Ivw==
X-Gm-Message-State: AOAM533R+bM4LEDf4+3Eu1O/cJivtILXmtfZxYnYIrefkOmfi6tekn5p
 fKfZUwXX/9bfIaTyR4W1nSoCa/YLwX3AcA==
X-Google-Smtp-Source: ABdhPJyto6oGJpRqyfOM7aocdnKqMYaReM6+HGONklHUYzjPh4qQb/sycpqQ+ua+FjYpfEhmssmmmg==
X-Received: by 2002:a50:aa8c:0:b0:410:801c:4e2f with SMTP id
 q12-20020a50aa8c000000b00410801c4e2fmr10752783edc.179.1645873012160; 
 Sat, 26 Feb 2022 02:56:52 -0800 (PST)
Received: from ars3 ([2a02:8109:8ac0:56d0::758e])
 by smtp.gmail.com with ESMTPSA id
 o14-20020a170906774e00b006d5b915f27dsm2086897ejn.169.2022.02.26.02.56.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 26 Feb 2022 02:56:51 -0800 (PST)
From: Augusto Stoffel <arstoffel@HIDDEN>
To: David Fussner <dfussner@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <87pmnad7n3.fsf@HIDDEN>
 <CADF+Rti7JdViHpksyO7cnHy_gj8bCUDkXV0OfAP8Q-CfZn2mkw@HIDDEN>
Date: Sat, 26 Feb 2022 11:56:50 +0100
In-Reply-To: <CADF+Rti7JdViHpksyO7cnHy_gj8bCUDkXV0OfAP8Q-CfZn2mkw@HIDDEN>
 (David Fussner's message of "Sat, 26 Feb 2022 09:29:06 +0000")
Message-ID: <87czj9dhfx.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::532
 (failed)
Received-SPF: pass client-ip=2a00:1450:4864:20::532;
 envelope-from=arstoffel@HIDDEN; helo=mail-ed1-x532.google.com
X-Spam_score_int: -6
X-Spam_score: -0.7
X-Spam_bar: /
X-Spam_report: (-0.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 PDS_HP_HELO_NORDNS=0.659, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
Cc: 53749 <at> debbugs.gnu.org, "David Fussner via Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On Sat, 26 Feb 2022 at 09:29, David Fussner <dfussner@HIDDEN> wrote:

> Hi Augusto,
>
> On Fri, 25 Feb 2022 at 20:16, Augusto Stoffel <arstoffel@HIDDEN> wrote:
>>
>> Hi David,
>
>>
>> I took a superficial look at this thread, and this seems very nice.
>
> Thanks!
>
>>
>> I was wondering why you want to be able to find the definition of macros
>> with @ in their name.  Those are "private" macros that the user
>> shouldn't have occasion to use.  Is it for a TeX programmer mode?
>
> I confess that TeX developers are indeed one of the main targets for
> the feature as I envisioned it.  For creating and following \labels,
> \refs, and \cites (of all sorts) I find RefTeX very handy, as well as
> for jumping around \chapters and \sections and the like.  What I miss
> when developing are the code-navigation features of something like
> xref, which are (from the user point of view) both simple and
> powerful.  My modest goal was to make Emacs' extensive infrastructure
> work a little better out of the box for TeX documents, especially for
> styles and other collections of macros.

Sorry for entering a tangent, but here's one more thing I dislike about
RefTeX you might want to consider.  If you type \label{something}, as
opposed to using the RefTeX command to add a label (or if you edit the
label by hand) then RefTeX will not reparse the document and get out of
sync.  Or at least that was the case when I still used RefTeX.  So it
might be worth considering some cache invalidation scheme there.
(Digestif has caching for multifile documents, but parsing a single file
is fast enough that this is not a problem I need to worry :-).)

>>
>> Let me also mention a library I wrote for analyzing TeX code (accessible
>> to Emacs via LSP):
>>
>>     https://github.com/astoff/digestif
>>
>> It's written in Lua (can run on the LuaTeX interpreter) and uses PEGs
>> for flexible parsing.  If you want to be very ambitious about what you
>> are able to parse, I think regexps are not sufficient.
>>
>> Digestif can handle \cite{messed up reference} just fine, for example.
>>
>
> This looks very nice indeed, and if I'm reading it right provides a
> replacement both for RefTeX and for the code-navigation features I'm
> trying to implement.

That's right.  Also command completion (including snippets, if that's
your thing) and Eldoc.

>  I figure I'll continue trying to get improved
> out-of-the-box features into core, and if I manage to satisfy Dmitry
> we'll then have a choice, but in any case I'm going to have a longer
> look at digestif when I get some time.

Let me mention one last thing, since you seem interested in a TeX
programming mode.

Digestif will not work great out of the box for programming because it
correctly considers @ to have catcode "other" (so it can't be part of
the name of a command).  But this is trivial to change and, in fact,
Digestif already has a "latex-prog" mode that simulates the correct
catcodes.  It would be easy to include a "latex-expl3" mode as well.

The problem is that there's no way for Emacs to communicate that one of
these programming modes is to be used.  This could be fixed in two ways:

A. by creating latex-prog and latex-expl3 derived modes in Emacs, or

B. adding heuristics to Digestif to decide if a given file is "document"
   or "code".

Do you have any thoughts about A?  Would there be any other benefits in
Emacs to justify the latex-prog and latex-expl3 major modes?  It seems
that (at least in AUCTeX) @ is always considered a letter, which may be
innocuous but is kinda wrong.

>
> Thanks for the hint!
>
> David.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 26 Feb 2022 09:29:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 26 04:29:32 2022
Received: from localhost ([127.0.0.1]:54296 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nNtOO-0005cd-5T
	for submit <at> debbugs.gnu.org; Sat, 26 Feb 2022 04:29:32 -0500
Received: from mail-qk1-f170.google.com ([209.85.222.170]:36354)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dfussner@HIDDEN>) id 1nNtOF-0005c5-La
 for 53749 <at> debbugs.gnu.org; Sat, 26 Feb 2022 04:29:24 -0500
Received: by mail-qk1-f170.google.com with SMTP id g24so6564986qkl.3
 for <53749 <at> debbugs.gnu.org>; Sat, 26 Feb 2022 01:29:23 -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=QCQ9aqQF2VgkXkjJXKe+ExzyiCy1QnZKHQ5H+PCQXpI=;
 b=HIn811gh+Jc0o/BUZ6t1v+zQfvF6lr2edfonkYLeK+KdX0qr45Hn/mpaPu8wDk6zyI
 sW5UmUfOI86t6sT6C9cCr3GqSFlXxVTfRljKQmu2AQm6yqfEJUeBZVXl9T+5EuHFB6Rn
 ELQzecofeKwr/7EW5ck84ZNr93cBhPGapT5aofqJ4aVOvTIOvyPCMWiSZaek/FfHFmz6
 pkQ9MBb3i37zyido9tT/5G4yr1TRTfOgC6ul/TBee6cScA5H4d7DCmLRvFP2tQX5QyUF
 QFXSbLCRO/RJT/gHT276KefVlGGCTCtVg7Z5nLGnRDkrMmt4SmZTLFfbJrHVrwSyPmJD
 Yrsg==
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=QCQ9aqQF2VgkXkjJXKe+ExzyiCy1QnZKHQ5H+PCQXpI=;
 b=u+BkHtwICIYrMCl2lGCZY6M59xaz582OYv+9mt6IQTgqzsjvnZq/2DDU0Trnh+nsbN
 PpNbJIcdRbeZmOmIMK1aE9zaopSleHZ2jZnDRWb9KQQL/lp9pPq0uWcnVpGcGB6LDwM7
 f3Rz6QoqF5atBYHHNLGYs0ijuCrRTTlRZvMmVLUUgsnIEAW9iUFVYPZ2jue3IrXZltMw
 mjXdiZjWOEuLTY2cIvnn1UEsujsex2nP2ZAjkSp6wpdnAOttK2bq8Q1Rsodhmz6iSgpB
 +QIIr3FP2HRVXFUwEa/OjNlSK7BOeA7sgvdtRXNBZa9uDR90CjVaD+TNMPXF4p1g2pDs
 VHLQ==
X-Gm-Message-State: AOAM531O1NZF7pU1k8zT6CxlgXXLCu2+nfhxsI8/88BgI7ZLkIxXlVmi
 OUMZyA4TkGTgAiBNorK3Yu6J1GOgVcUUL1h5km0=
X-Google-Smtp-Source: ABdhPJxD2uIvSagDTxAakvQVcDMJpunL8m0eLgVUMJRahlDmDZcQBJ6vMq6XXWoGSoBKp0MEFApWJWatXWn+BsDFl8Y=
X-Received: by 2002:a37:4147:0:b0:47c:4595:b8c with SMTP id
 o68-20020a374147000000b0047c45950b8cmr6917449qka.267.1645867757950; Sat, 26
 Feb 2022 01:29:17 -0800 (PST)
MIME-Version: 1.0
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <87pmnad7n3.fsf@HIDDEN>
In-Reply-To: <87pmnad7n3.fsf@HIDDEN>
From: David Fussner <dfussner@HIDDEN>
Date: Sat, 26 Feb 2022 09:29:06 +0000
Message-ID: <CADF+Rti7JdViHpksyO7cnHy_gj8bCUDkXV0OfAP8Q-CfZn2mkw@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
To: Augusto Stoffel <arstoffel@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org, "David Fussner via Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Augusto,

On Fri, 25 Feb 2022 at 20:16, Augusto Stoffel <arstoffel@HIDDEN> wrote:
>
> Hi David,

>
> I took a superficial look at this thread, and this seems very nice.

Thanks!

>
> I was wondering why you want to be able to find the definition of macros
> with @ in their name.  Those are "private" macros that the user
> shouldn't have occasion to use.  Is it for a TeX programmer mode?

I confess that TeX developers are indeed one of the main targets for
the feature as I envisioned it.  For creating and following \labels,
\refs, and \cites (of all sorts) I find RefTeX very handy, as well as
for jumping around \chapters and \sections and the like.  What I miss
when developing are the code-navigation features of something like
xref, which are (from the user point of view) both simple and
powerful.  My modest goal was to make Emacs' extensive infrastructure
work a little better out of the box for TeX documents, especially for
styles and other collections of macros.

>
> Let me also mention a library I wrote for analyzing TeX code (accessible
> to Emacs via LSP):
>
>     https://github.com/astoff/digestif
>
> It's written in Lua (can run on the LuaTeX interpreter) and uses PEGs
> for flexible parsing.  If you want to be very ambitious about what you
> are able to parse, I think regexps are not sufficient.
>
> Digestif can handle \cite{messed up reference} just fine, for example.
>

This looks very nice indeed, and if I'm reading it right provides a
replacement both for RefTeX and for the code-navigation features I'm
trying to implement.  I figure I'll continue trying to get improved
out-of-the-box features into core, and if I manage to satisfy Dmitry
we'll then have a choice, but in any case I'm going to have a longer
look at digestif when I get some time.

Thanks for the hint!

David.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 26 Feb 2022 09:29:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 26 04:29:24 2022
Received: from localhost ([127.0.0.1]:54293 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nNtOF-0005cI-Ld
	for submit <at> debbugs.gnu.org; Sat, 26 Feb 2022 04:29:24 -0500
Received: from lists.gnu.org ([209.51.188.17]:39174)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dfussner@HIDDEN>) id 1nNtOD-0005cA-Gm
 for submit <at> debbugs.gnu.org; Sat, 26 Feb 2022 04:29:22 -0500
Received: from eggs.gnu.org ([209.51.188.92]:38630)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <dfussner@HIDDEN>)
 id 1nNtOD-0004mn-2x
 for bug-gnu-emacs@HIDDEN; Sat, 26 Feb 2022 04:29:21 -0500
Received: from [2607:f8b0:4864:20::735] (port=45755
 helo=mail-qk1-x735.google.com)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <dfussner@HIDDEN>)
 id 1nNtOB-0002U3-C1
 for bug-gnu-emacs@HIDDEN; Sat, 26 Feb 2022 04:29:20 -0500
Received: by mail-qk1-x735.google.com with SMTP id b13so6523576qkj.12
 for <bug-gnu-emacs@HIDDEN>; Sat, 26 Feb 2022 01:29:18 -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=QCQ9aqQF2VgkXkjJXKe+ExzyiCy1QnZKHQ5H+PCQXpI=;
 b=HIn811gh+Jc0o/BUZ6t1v+zQfvF6lr2edfonkYLeK+KdX0qr45Hn/mpaPu8wDk6zyI
 sW5UmUfOI86t6sT6C9cCr3GqSFlXxVTfRljKQmu2AQm6yqfEJUeBZVXl9T+5EuHFB6Rn
 ELQzecofeKwr/7EW5ck84ZNr93cBhPGapT5aofqJ4aVOvTIOvyPCMWiSZaek/FfHFmz6
 pkQ9MBb3i37zyido9tT/5G4yr1TRTfOgC6ul/TBee6cScA5H4d7DCmLRvFP2tQX5QyUF
 QFXSbLCRO/RJT/gHT276KefVlGGCTCtVg7Z5nLGnRDkrMmt4SmZTLFfbJrHVrwSyPmJD
 Yrsg==
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=QCQ9aqQF2VgkXkjJXKe+ExzyiCy1QnZKHQ5H+PCQXpI=;
 b=OfLHYdKA/hQWUWnAk5b93l5U+72AOG3o5Od2w7zM4X84lS3EY8LZKTi72i1Kv05MEj
 kC4eCJ+ccwNyBsQCU1xFdJqBRo7FaIkV7YwSR2aEL9bN1lxYKUiDidyRKDERH8UZVOje
 ih8m/gvpIEnC+U4o6QfWy4+4jg9QEtM6nrOolGAiOwFYzYI00NDo9kNtl6CKFP0BnRsT
 JvEpMelEMJMhXZ7OzarNIBiM11a1FfpU6tjc5kezDcrCIwNfsnsGkmPHUCDW00fIO1GC
 UBKOuyYTzZSuVAGh8axnrArdJd8mkJlGVbcIjhz+lGalWmpyQMuBVipV269iMekuXjlf
 1tgA==
X-Gm-Message-State: AOAM531D2PtBbOJ1FRo9kAfM/2THdSORjx2LB99ar1Zc5lEm3oGJkFKz
 4NrBxCYlA1dRhtCXigsBqE7wSxqJtMq9QyBqS7k=
X-Google-Smtp-Source: ABdhPJxD2uIvSagDTxAakvQVcDMJpunL8m0eLgVUMJRahlDmDZcQBJ6vMq6XXWoGSoBKp0MEFApWJWatXWn+BsDFl8Y=
X-Received: by 2002:a37:4147:0:b0:47c:4595:b8c with SMTP id
 o68-20020a374147000000b0047c45950b8cmr6917449qka.267.1645867757950; Sat, 26
 Feb 2022 01:29:17 -0800 (PST)
MIME-Version: 1.0
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <87pmnad7n3.fsf@HIDDEN>
In-Reply-To: <87pmnad7n3.fsf@HIDDEN>
From: David Fussner <dfussner@HIDDEN>
Date: Sat, 26 Feb 2022 09:29:06 +0000
Message-ID: <CADF+Rti7JdViHpksyO7cnHy_gj8bCUDkXV0OfAP8Q-CfZn2mkw@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
To: Augusto Stoffel <arstoffel@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::735
 (failed)
Received-SPF: pass client-ip=2607:f8b0:4864:20::735;
 envelope-from=dfussner@HIDDEN; helo=mail-qk1-x735.google.com
X-Spam_score_int: -6
X-Spam_score: -0.7
X-Spam_bar: /
X-Spam_report: (-0.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 PDS_HP_HELO_NORDNS=0.659, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
Cc: 53749 <at> debbugs.gnu.org, "David Fussner via Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

Hi Augusto,

On Fri, 25 Feb 2022 at 20:16, Augusto Stoffel <arstoffel@HIDDEN> wrote:
>
> Hi David,

>
> I took a superficial look at this thread, and this seems very nice.

Thanks!

>
> I was wondering why you want to be able to find the definition of macros
> with @ in their name.  Those are "private" macros that the user
> shouldn't have occasion to use.  Is it for a TeX programmer mode?

I confess that TeX developers are indeed one of the main targets for
the feature as I envisioned it.  For creating and following \labels,
\refs, and \cites (of all sorts) I find RefTeX very handy, as well as
for jumping around \chapters and \sections and the like.  What I miss
when developing are the code-navigation features of something like
xref, which are (from the user point of view) both simple and
powerful.  My modest goal was to make Emacs' extensive infrastructure
work a little better out of the box for TeX documents, especially for
styles and other collections of macros.

>
> Let me also mention a library I wrote for analyzing TeX code (accessible
> to Emacs via LSP):
>
>     https://github.com/astoff/digestif
>
> It's written in Lua (can run on the LuaTeX interpreter) and uses PEGs
> for flexible parsing.  If you want to be very ambitious about what you
> are able to parse, I think regexps are not sufficient.
>
> Digestif can handle \cite{messed up reference} just fine, for example.
>

This looks very nice indeed, and if I'm reading it right provides a
replacement both for RefTeX and for the code-navigation features I'm
trying to implement.  I figure I'll continue trying to get improved
out-of-the-box features into core, and if I manage to satisfy Dmitry
we'll then have a choice, but in any case I'm going to have a longer
look at digestif when I get some time.

Thanks for the hint!

David.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 25 Feb 2022 20:16:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 25 15:16:26 2022
Received: from localhost ([127.0.0.1]:53810 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nNh0s-0008Jm-44
	for submit <at> debbugs.gnu.org; Fri, 25 Feb 2022 15:16:26 -0500
Received: from mail-ed1-f54.google.com ([209.85.208.54]:39919)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <arstoffel@HIDDEN>) id 1nNh0q-0008JX-DA
 for 53749 <at> debbugs.gnu.org; Fri, 25 Feb 2022 15:16:25 -0500
Received: by mail-ed1-f54.google.com with SMTP id g20so8941764edw.6
 for <53749 <at> debbugs.gnu.org>; Fri, 25 Feb 2022 12:16:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version;
 bh=pOtJY65BSCDg5reHSC+XupwZ0t80w4yz2ZVZg70/NPM=;
 b=GYXELjg/pBo6hQT+aJ2L4VV4TUtbiGFSqxvajZZtkkqXAT6grRQomHjllLI2UwyIAS
 5hlPH0P0ZUOhMvLopGT7t5+Qbjoe8DwbU5evHdWNi2ZbZyP1/oFFyTgEuiDSKCEhF+CN
 qrsYdiaAVyqtuTUu4W+PoQNjOJF0g2arS2eKDRA7L0fGSp8nHh3BbrhrKJXtLmqyhsZH
 XC4uKyvHE18rj12RNpKUyy7uv23k88h7JBWdQJ+Gyiq2sidgnAswEQKK/meMPbRTefUp
 O3V8hQq/9p+mgeigZleCgHlNBK8rxIT6BQDPgVzM+AFjplARx+l0dJtoThhqY7vPLYvl
 08ZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version;
 bh=pOtJY65BSCDg5reHSC+XupwZ0t80w4yz2ZVZg70/NPM=;
 b=XyXvWQDqpaxWyKM0iAZApEPyKmjKEg3TBwUQvHLCbwvoRHz0MP61IFEO7maC5ZC+Ng
 qSX2LY78xBTwecHld4KwYazbJdtnG/7m5KHIUqTw1/W9ELTNgAy8rPOMIM4y5qipPjUE
 pW6rMRdn8jDA+qxcTZuVE52P9B0yOJGA9a1jwzBAlj4Eun8L2uRGSiS/R6RgqfvCkMLJ
 TpXCky0pQRxoxtfQAXNnLYeTcSzA3V0v1HYNcdt8rxC7yH4gsyauEyaleSb47Esr0FcE
 NTGsNKWz475cz9ElmT5NaZyl59RFwx1nzCKiH7X6oNbAHmiNz9AGepnTHRNP6NxoWyT4
 cK/A==
X-Gm-Message-State: AOAM533YSleFgFPKLsjcJJgfonGoAgbfTHvv3DzXKkCi+FXZFetz/t2i
 a/V2AzU/6zPYCxWKOpLDf1s=
X-Google-Smtp-Source: ABdhPJzkrNg5/WBOm2QpdYQfT2LHEAhiHWZc3ImETfIBiHNhwVOdJZUb6waM9FYAvPWOmXgDfKgHNw==
X-Received: by 2002:a50:ee90:0:b0:40f:349f:7368 with SMTP id
 f16-20020a50ee90000000b0040f349f7368mr8488283edr.236.1645820178223; 
 Fri, 25 Feb 2022 12:16:18 -0800 (PST)
Received: from ars3 ([2a02:8109:8ac0:56d0::758e])
 by smtp.gmail.com with ESMTPSA id
 n23-20020a509357000000b00412b325b05fsm1750361eda.74.2022.02.25.12.16.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 25 Feb 2022 12:16:17 -0800 (PST)
From: Augusto Stoffel <arstoffel@HIDDEN>
To: David Fussner via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
Date: Fri, 25 Feb 2022 21:16:16 +0100
In-Reply-To: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 (David Fussner via's message of "Thu, 3 Feb 2022 15:09:22 +0000")
Message-ID: <87pmnad7n3.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org, David Fussner <dfussner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi David,

I took a superficial look at this thread, and this seems very nice.

I was wondering why you want to be able to find the definition of macros
with @ in their name.  Those are "private" macros that the user
shouldn't have occasion to use.  Is it for a TeX programmer mode?

Let me also mention a library I wrote for analyzing TeX code (accessible
to Emacs via LSP):

    https://github.com/astoff/digestif

It's written in Lua (can run on the LuaTeX interpreter) and uses PEGs
for flexible parsing.  If you want to be very ambitious about what you
are able to parse, I think regexps are not sufficient.

Digestif can handle \cite{messed up reference} just fine, for example.

On Thu,  3 Feb 2022 at 15:09, David Fussner via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> wrote:

> I've recently been trying to use xref commands with a tags table in a
> TeX repository, and many of the results are sub-optimal.  This is a
> known issue -- within living memory there have been at least two
> discussions related to it on help-gnu-emacs:
>
> https://lists.gnu.org/archive/html/help-gnu-emacs/2018-06/msg00126.html
> https://lists.gnu.org/archive/html/help-gnu-emacs/2021-07/msg00436.html
>
> Neither discussion resulted in any code, at least not that I can find,
> and the issues mentioned there remain.  For example,
> xref-find-definitions on, say, '\mycommand' returns
>
> No definitions found for: mycommand.
>
> (The absence of the escape char in the search string makes the search
> fail, as the tag name in the table will be '\mycommand'.)
>
> Similarly, any xref command on 'my:citekey' will only search by default
> for the half of the symbol under point, stopping at the colon.
>
> 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.
>
> A few remarks:
>
> 1. The code should work as it stands both in the AUCTeX and the in-tree
> modes.  The AUCTeX hooks I've included in the patch are provisional, as
> I would want to discuss with them how they would want to handle it,
> should the patch be accepted in some form.
>
> 2. Along the way I found some issues with how etags parses TeX files,
> issues which affect the usefulness of the xref commands, so I've made
> changes in etags.c as well.  When running the test suite for etags the
> only diffs occurred in the TeX-related sections of the resulting tags
> file, and location information in those sections was good.
>
> 3. The patch as it stands enables all the changes by default to give
> what I judge to be the best out-of-the-box experience, but wiser heads
> may well have other ideas.
>
> 4. If it looks like the patch will make it into Emacs in some form, I'm
> going to need to assign copyright, so I'd appreciate help with getting
> that started.
>
> Thanks,
>
> David.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 25 Feb 2022 20:16:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 25 15:16:36 2022
Received: from localhost ([127.0.0.1]:53813 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nNh12-0008KA-Fa
	for submit <at> debbugs.gnu.org; Fri, 25 Feb 2022 15:16:36 -0500
Received: from lists.gnu.org ([209.51.188.17]:42116)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <arstoffel@HIDDEN>) id 1nNh0v-0008Jw-6D
 for submit <at> debbugs.gnu.org; Fri, 25 Feb 2022 15:16:29 -0500
Received: from eggs.gnu.org ([209.51.188.92]:50848)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <arstoffel@HIDDEN>)
 id 1nNh0q-0006XV-Vu
 for bug-gnu-emacs@HIDDEN; Fri, 25 Feb 2022 15:16:29 -0500
Received: from [2a00:1450:4864:20::533] (port=38667
 helo=mail-ed1-x533.google.com)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <arstoffel@HIDDEN>)
 id 1nNh0m-00009h-3Z
 for bug-gnu-emacs@HIDDEN; Fri, 25 Feb 2022 15:16:23 -0500
Received: by mail-ed1-x533.google.com with SMTP id s24so8937732edr.5
 for <bug-gnu-emacs@HIDDEN>; Fri, 25 Feb 2022 12:16:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version;
 bh=pOtJY65BSCDg5reHSC+XupwZ0t80w4yz2ZVZg70/NPM=;
 b=GYXELjg/pBo6hQT+aJ2L4VV4TUtbiGFSqxvajZZtkkqXAT6grRQomHjllLI2UwyIAS
 5hlPH0P0ZUOhMvLopGT7t5+Qbjoe8DwbU5evHdWNi2ZbZyP1/oFFyTgEuiDSKCEhF+CN
 qrsYdiaAVyqtuTUu4W+PoQNjOJF0g2arS2eKDRA7L0fGSp8nHh3BbrhrKJXtLmqyhsZH
 XC4uKyvHE18rj12RNpKUyy7uv23k88h7JBWdQJ+Gyiq2sidgnAswEQKK/meMPbRTefUp
 O3V8hQq/9p+mgeigZleCgHlNBK8rxIT6BQDPgVzM+AFjplARx+l0dJtoThhqY7vPLYvl
 08ZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version;
 bh=pOtJY65BSCDg5reHSC+XupwZ0t80w4yz2ZVZg70/NPM=;
 b=vofO5TVpwwyV3RjKEAGKhhKGVXyJJP6RxAW5KHusraJE/bdZ9hJMLkZ+IAxJXySSgj
 1w6riQjMTWEot8C+2IVT1keBDJ0fexEcZ7fUgMempFAeOsGERqSoXY/M5WvMYBDUAHaN
 wlGrDeTvV2EpyFevmfyKSIF5fmt9Iv76gWEKiNz6XMGVAQKqZmwI6K8XUv4BWxPJN4+E
 ES8Holo9ggWxqU2tlqXnI8GATMznMrHmFOlpU6gnd+ZWXobJ2OvN7wjxE4IMTo5mjOsT
 uoW/tQGFnEYUZBcJlSsZ64fMSzVFGyRSb9ksf9AxF6AL402cFlB2CWrRqqSHwG2n2VRB
 EyrQ==
X-Gm-Message-State: AOAM533wO1h0MtQTXJy22rKzdGgSjRNCvlUW2ySGs9sJKRauXdo8gocX
 Er9+qkchuS2yjxCdzpgaXas=
X-Google-Smtp-Source: ABdhPJzkrNg5/WBOm2QpdYQfT2LHEAhiHWZc3ImETfIBiHNhwVOdJZUb6waM9FYAvPWOmXgDfKgHNw==
X-Received: by 2002:a50:ee90:0:b0:40f:349f:7368 with SMTP id
 f16-20020a50ee90000000b0040f349f7368mr8488283edr.236.1645820178223; 
 Fri, 25 Feb 2022 12:16:18 -0800 (PST)
Received: from ars3 ([2a02:8109:8ac0:56d0::758e])
 by smtp.gmail.com with ESMTPSA id
 n23-20020a509357000000b00412b325b05fsm1750361eda.74.2022.02.25.12.16.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 25 Feb 2022 12:16:17 -0800 (PST)
From: Augusto Stoffel <arstoffel@HIDDEN>
To: David Fussner via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
Date: Fri, 25 Feb 2022 21:16:16 +0100
In-Reply-To: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 (David Fussner via's message of "Thu, 3 Feb 2022 15:09:22 +0000")
Message-ID: <87pmnad7n3.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::533
 (failed)
Received-SPF: pass client-ip=2a00:1450:4864:20::533;
 envelope-from=arstoffel@HIDDEN; helo=mail-ed1-x533.google.com
X-Spam_score_int: -6
X-Spam_score: -0.7
X-Spam_bar: /
X-Spam_report: (-0.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 PDS_HP_HELO_NORDNS=0.659, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
Cc: 53749 <at> debbugs.gnu.org, David Fussner <dfussner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

Hi David,

I took a superficial look at this thread, and this seems very nice.

I was wondering why you want to be able to find the definition of macros
with @ in their name.  Those are "private" macros that the user
shouldn't have occasion to use.  Is it for a TeX programmer mode?

Let me also mention a library I wrote for analyzing TeX code (accessible
to Emacs via LSP):

    https://github.com/astoff/digestif

It's written in Lua (can run on the LuaTeX interpreter) and uses PEGs
for flexible parsing.  If you want to be very ambitious about what you
are able to parse, I think regexps are not sufficient.

Digestif can handle \cite{messed up reference} just fine, for example.

On Thu,  3 Feb 2022 at 15:09, David Fussner via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> wrote:

> I've recently been trying to use xref commands with a tags table in a
> TeX repository, and many of the results are sub-optimal.  This is a
> known issue -- within living memory there have been at least two
> discussions related to it on help-gnu-emacs:
>
> https://lists.gnu.org/archive/html/help-gnu-emacs/2018-06/msg00126.html
> https://lists.gnu.org/archive/html/help-gnu-emacs/2021-07/msg00436.html
>
> Neither discussion resulted in any code, at least not that I can find,
> and the issues mentioned there remain.  For example,
> xref-find-definitions on, say, '\mycommand' returns
>
> No definitions found for: mycommand.
>
> (The absence of the escape char in the search string makes the search
> fail, as the tag name in the table will be '\mycommand'.)
>
> Similarly, any xref command on 'my:citekey' will only search by default
> for the half of the symbol under point, stopping at the colon.
>
> 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.
>
> A few remarks:
>
> 1. The code should work as it stands both in the AUCTeX and the in-tree
> modes.  The AUCTeX hooks I've included in the patch are provisional, as
> I would want to discuss with them how they would want to handle it,
> should the patch be accepted in some form.
>
> 2. Along the way I found some issues with how etags parses TeX files,
> issues which affect the usefulness of the xref commands, so I've made
> changes in etags.c as well.  When running the test suite for etags the
> only diffs occurred in the TeX-related sections of the resulting tags
> file, and location information in those sections was good.
>
> 3. The patch as it stands enables all the changes by default to give
> what I judge to be the best out-of-the-box experience, but wiser heads
> may well have other ideas.
>
> 4. If it looks like the patch will make it into Emacs in some form, I'm
> going to need to assign copyright, so I'd appreciate help with getting
> that started.
>
> Thanks,
>
> David.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 24 Feb 2022 13:16:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 24 08:16:02 2022
Received: from localhost ([127.0.0.1]:47827 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nNDyU-0003Ac-5J
	for submit <at> debbugs.gnu.org; Thu, 24 Feb 2022 08:16:02 -0500
Received: from mail-qv1-f43.google.com ([209.85.219.43]:42596)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dfussner@HIDDEN>) id 1nNDyR-0003A1-Er
 for 53749 <at> debbugs.gnu.org; Thu, 24 Feb 2022 08:16:00 -0500
Received: by mail-qv1-f43.google.com with SMTP id e22so3382427qvf.9
 for <53749 <at> 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)
MIME-Version: 1.0
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <1de34060-e93b-0a42-fff5-20e283abe0dc@HIDDEN>
 <CADF+RthLfZVgu72wnPXf2=w-gnKZT+4eWR_kmDVMnFvBY8f1XQ@HIDDEN>
 <CADF+Rtho+2qOpGB6hn-Cpyx4qrUJd9c3+wAxsGtySi75pxzbsQ@HIDDEN>
 <2f41ba40-9c3f-ac65-ef0d-300bd11c4867@HIDDEN>
 <CADF+Rth7ZYNk5vKo8FCkDvP1maFSJkje6h6Fyi+GA_7uVQxsEQ@HIDDEN>
 <300e30e1-aeea-ffa5-fa13-d541ccbffe30@HIDDEN>
 <CADF+Rtib+y+9yzCG1NZFjZCa7np=sc2rFkrQ-tsLCFjSpw=+0Q@HIDDEN>
 <b88c334e-02a5-c259-fd78-4e6c14d47a77@HIDDEN>
In-Reply-To: <b88c334e-02a5-c259-fd78-4e6c14d47a77@HIDDEN>
From: David Fussner <dfussner@HIDDEN>
Date: Thu, 24 Feb 2022 13:15:41 +0000
Message-ID: <CADF+RtiAZgzXDvRA_=C4+=A8eKjPGwmfj05RdqAj8xq=QDjFxA@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
To: Dmitry Gutov <dgutov@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Thanks Dmitry.  I'll post back here when I've got something.

David.

On Thu, 24 Feb 2022 at 02:23, Dmitry Gutov <dgutov@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 24 Feb 2022 02:23:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 23 21:23:58 2022
Received: from localhost ([127.0.0.1]:46942 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nN3nS-00081K-9k
	for submit <at> debbugs.gnu.org; Wed, 23 Feb 2022 21:23:58 -0500
Received: from mail-wr1-f46.google.com ([209.85.221.46]:42529)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1nN3nQ-000815-Id
 for 53749 <at> debbugs.gnu.org; Wed, 23 Feb 2022 21:23:57 -0500
Received: by mail-wr1-f46.google.com with SMTP id d17so738180wrc.9
 for <53749 <at> 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)
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)
Message-ID: <b88c334e-02a5-c259-fd78-4e6c14d47a77@HIDDEN>
Date: Thu, 24 Feb 2022 04:23:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
Content-Language: en-US
To: David Fussner <dfussner@HIDDEN>
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <1de34060-e93b-0a42-fff5-20e283abe0dc@HIDDEN>
 <CADF+RthLfZVgu72wnPXf2=w-gnKZT+4eWR_kmDVMnFvBY8f1XQ@HIDDEN>
 <CADF+Rtho+2qOpGB6hn-Cpyx4qrUJd9c3+wAxsGtySi75pxzbsQ@HIDDEN>
 <2f41ba40-9c3f-ac65-ef0d-300bd11c4867@HIDDEN>
 <CADF+Rth7ZYNk5vKo8FCkDvP1maFSJkje6h6Fyi+GA_7uVQxsEQ@HIDDEN>
 <300e30e1-aeea-ffa5-fa13-d541ccbffe30@HIDDEN>
 <CADF+Rtib+y+9yzCG1NZFjZCa7np=sc2rFkrQ-tsLCFjSpw=+0Q@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <CADF+Rtib+y+9yzCG1NZFjZCa7np=sc2rFkrQ-tsLCFjSpw=+0Q@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 23 Feb 2022 10:45:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 23 05:45:49 2022
Received: from localhost ([127.0.0.1]:43945 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nMp9Y-0007dJ-Tp
	for submit <at> debbugs.gnu.org; Wed, 23 Feb 2022 05:45:49 -0500
Received: from mail-qv1-f43.google.com ([209.85.219.43]:35328)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dfussner@HIDDEN>) id 1nMp9X-0007d6-DI
 for 53749 <at> debbugs.gnu.org; Wed, 23 Feb 2022 05:45:47 -0500
Received: by mail-qv1-f43.google.com with SMTP id 8so7579558qvf.2
 for <53749 <at> 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)
MIME-Version: 1.0
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <1de34060-e93b-0a42-fff5-20e283abe0dc@HIDDEN>
 <CADF+RthLfZVgu72wnPXf2=w-gnKZT+4eWR_kmDVMnFvBY8f1XQ@HIDDEN>
 <CADF+Rtho+2qOpGB6hn-Cpyx4qrUJd9c3+wAxsGtySi75pxzbsQ@HIDDEN>
 <2f41ba40-9c3f-ac65-ef0d-300bd11c4867@HIDDEN>
 <CADF+Rth7ZYNk5vKo8FCkDvP1maFSJkje6h6Fyi+GA_7uVQxsEQ@HIDDEN>
 <300e30e1-aeea-ffa5-fa13-d541ccbffe30@HIDDEN>
In-Reply-To: <300e30e1-aeea-ffa5-fa13-d541ccbffe30@HIDDEN>
From: David Fussner <dfussner@HIDDEN>
Date: Wed, 23 Feb 2022 10:45:28 +0000
Message-ID: <CADF+Rtib+y+9yzCG1NZFjZCa7np=sc2rFkrQ-tsLCFjSpw=+0Q@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
To: Dmitry Gutov <dgutov@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Dmitry,

Thanks again for looking at all this, and for your patience.

On Wed, 23 Feb 2022 at 02:21, Dmitry Gutov <dgutov@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 23 Feb 2022 02:21:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 22 21:21:31 2022
Received: from localhost ([127.0.0.1]:43255 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nMhHU-0008Os-6S
	for submit <at> debbugs.gnu.org; Tue, 22 Feb 2022 21:21:31 -0500
Received: from mail-wm1-f53.google.com ([209.85.128.53]:39635)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1nMhHR-0008Ob-U5
 for 53749 <at> debbugs.gnu.org; Tue, 22 Feb 2022 21:21:27 -0500
Received: by mail-wm1-f53.google.com with SMTP id
 n13-20020a05600c3b8d00b0037bff8a24ebso564532wms.4
 for <53749 <at> 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)
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)
Message-ID: <300e30e1-aeea-ffa5-fa13-d541ccbffe30@HIDDEN>
Date: Wed, 23 Feb 2022 04:21:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
Content-Language: en-US
To: David Fussner <dfussner@HIDDEN>
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <1de34060-e93b-0a42-fff5-20e283abe0dc@HIDDEN>
 <CADF+RthLfZVgu72wnPXf2=w-gnKZT+4eWR_kmDVMnFvBY8f1XQ@HIDDEN>
 <CADF+Rtho+2qOpGB6hn-Cpyx4qrUJd9c3+wAxsGtySi75pxzbsQ@HIDDEN>
 <2f41ba40-9c3f-ac65-ef0d-300bd11c4867@HIDDEN>
 <CADF+Rth7ZYNk5vKo8FCkDvP1maFSJkje6h6Fyi+GA_7uVQxsEQ@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <CADF+Rth7ZYNk5vKo8FCkDvP1maFSJkje6h6Fyi+GA_7uVQxsEQ@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 22 Feb 2022 15:19:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 22 10:19:49 2022
Received: from localhost ([127.0.0.1]:42372 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nMWxA-0000Js-Of
	for submit <at> debbugs.gnu.org; Tue, 22 Feb 2022 10:19:49 -0500
Received: from mail-qv1-f53.google.com ([209.85.219.53]:39476)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dfussner@HIDDEN>) id 1nMWx9-0000Jg-HJ
 for 53749 <at> debbugs.gnu.org; Tue, 22 Feb 2022 10:19:48 -0500
Received: by mail-qv1-f53.google.com with SMTP id a1so1812144qvl.6
 for <53749 <at> debbugs.gnu.org>; Tue, 22 Feb 2022 07:19: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=SfYAfmYsi50+ee/1Moo5O7y7aqGh9KvJHZHat2yssAA=;
 b=cZpOI8QbKBkrlVQJ+j6OcRRUnfIWSTDZfTRlxRO9AffWeKUsoJpZy/HFM097HB55Ut
 PaHwc1J6Yjrki6/FtuRng9R6DTTHqo9azWQo3Q3B72E1vEVZ/SnbuG3OyBMobxdmnZQO
 CuepEmwWeDBFXTch9yfdAAx37tMgBxRBLCToIi6Czah+Ad7sGJ0bxeh5FuUwIfCfB7Q4
 pvQbx/hxUveiBDmyCE77TUTQoT2jE4gZPhsqzvsuSNgm+1KTgu2Mgv6caU6OC1XN8bSu
 FmQ7isFmB7CLI/QwJfGOjte2iOZvarOkmm8pMg/PrEoNtTatgFl3lFdKkYrZXt2ScqjR
 NiRw==
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=SfYAfmYsi50+ee/1Moo5O7y7aqGh9KvJHZHat2yssAA=;
 b=M/tajhNWGSfqv4aJuGqz5XIjiRjYYHLkFMBjwf736j22qJM5JEiI+ATn6xMh8qyj9e
 55t7uAw2LRwEgn4KAeEFNlOWfW/k6Du/vNAtqT95A7sRBlLiWSHa9pwHM1Jc/eJeHWRX
 Y48+DWo8S/pGuaIan6LvSWUBJaX3giv+NXKZlpE2vrH9pk3/paR0N4BLK1/1h0UkdTF1
 /D+zwMk2f3wN/il/sEU4qFGX9n6MUrmvaMM1oOWA69EC83RiU/+7E22qOU+x9m6lQp5F
 H8Qko0iTEgLtU3l7zNPSx2JuFiHRa5vMymijEuhyvv9PgesGXlAxMqQmLVCc7bjGJuOg
 gSPw==
X-Gm-Message-State: AOAM531NLcUW8VxSU0LywXekcLQaW+BkPRgRKT7UUD+3rExSQ9V6F7uz
 g3AiNH4WNgiLBXvTCqO3CFYNmeYZopjP6gcWWrNyPt1rREtXug==
X-Google-Smtp-Source: ABdhPJwZI/PUxBY23lzDesrkBP+eeXe4XMqdNQvarZSp18mx0JCI4D28f6SuiHdwnDz6zdgYJff+Ss/8DiRKs0XhWRw=
X-Received: by 2002:ac8:5c4f:0:b0:2dc:8e84:b0ac with SMTP id
 j15-20020ac85c4f000000b002dc8e84b0acmr22774982qtj.536.1645543181717; Tue, 22
 Feb 2022 07:19:41 -0800 (PST)
MIME-Version: 1.0
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <1de34060-e93b-0a42-fff5-20e283abe0dc@HIDDEN>
 <CADF+RthLfZVgu72wnPXf2=w-gnKZT+4eWR_kmDVMnFvBY8f1XQ@HIDDEN>
 <CADF+Rtho+2qOpGB6hn-Cpyx4qrUJd9c3+wAxsGtySi75pxzbsQ@HIDDEN>
 <2f41ba40-9c3f-ac65-ef0d-300bd11c4867@HIDDEN>
In-Reply-To: <2f41ba40-9c3f-ac65-ef0d-300bd11c4867@HIDDEN>
From: David Fussner <dfussner@HIDDEN>
Date: Tue, 22 Feb 2022 15:19:29 +0000
Message-ID: <CADF+Rth7ZYNk5vKo8FCkDvP1maFSJkje6h6Fyi+GA_7uVQxsEQ@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
To: Dmitry Gutov <dgutov@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000cf132205d89ce09f"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--000000000000cf132205d89ce09f
Content-Type: text/plain; charset="UTF-8"

Hi Dmitry,

> 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.

\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.

> 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.

>  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 simplest fix is to remove the escape char from all tag names, which I
suggest to users of ctags in some commented-out code in etags.c. This does
lose the ability to differentiate \def'ed commands and \csdef'd ones,
especially as in some circumstances they can have the same name.  I'm not
sure how great a loss that is, on the other hand.  Is that what you had in
mind?

> 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?

David.

--000000000000cf132205d89ce09f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Dmitry,</div><div><br></div><div>&gt; Do you have =
a step-by-step scenario? Perhaps using one of the .texi<br>&gt; manuals alr=
eady existing in the repo?<br></div><div><br></div><div>I can&#39;t find a =
good example in the emacs repo, but I&#39;ll try to talk through what happe=
ns with a code snippet from biblatex.sty, which I hope will explain some of=
 the issues we&#39;re discussing, even if it is a little artificial.<br></d=
iv><div><br>\DeclareBiblatexOption{global,type}[string]{uniquename}[true]{%=
<br>=C2=A0 \ifcsdef{blx@opt@uniquename@#1}<br>=C2=A0 =C2=A0 {\letcs\blx@uni=
quename{blx@opt@uniquename@#1}}<br>=C2=A0 =C2=A0 {\blx@err@invopt{uniquenam=
e=3D#1}{}}}<br>\def\blx@opt@uniquename@false{false}<br>\def\blx@opt@uniquen=
ame@init{init}<br>\def\blx@opt@uniquename@true{full}<br>\def\blx@opt@unique=
name@full{full}<br>\def\blx@opt@uniquename@allinit{allinit}<br>\def\blx@opt=
@uniquename@allfull{allfull}<br>\def\blx@opt@uniquename@mininit{mininit}<br=
>\def\blx@opt@uniquename@minfull{minfull}</div><div><br></div><div>If you d=
o M-? on \ifcsdef{blx@opt@uniquename@#1} using the default backend, the def=
ault search string is blx@opt@uniquename@, and you&#39;ll get two hits, tha=
t line and the following one.=C2=A0 Stepping through xref-references-in-dir=
ectory shows that the semantic-symref search (using grep) only finds those =
two using the :searchtype &#39;symbol, and they&#39;re returned.=C2=A0 If y=
ou change &#39;symbol to &#39;regexp, grep finds all the matches in that co=
de snippet, but then xref--convert-hits uses (format &quot;\\_&lt;%s\\_&gt;=
&quot;), which again loses all but the first two hits when it scans the lis=
t provided by grep.=C2=A0 Either grep or emacs here will miss out on valid =
hits unless you change both the semantic-symref instantiation and the forma=
t specification.<br></div><div><br></div><div>&gt; One way to deal with tha=
t is to treat all user inputs as regexps there. Perhaps some will have to b=
e more verbose that ideal, but as=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &gt; long a=
s the user is familiar with the regexp syntax, the behavior will be both po=
werful and predictable</div><div><br></div><div>If I understand you right, =
I think that&#39;s what I&#39;m trying to do, but allowing for users who pe=
rhaps aren&#39;t too familiar with emacs regexps and who might typically ju=
st accept the default search string offered by xref.=C2=A0 <br></div><div><=
br></div><div>&gt;=C2=A0 Could those be disambiguated when the tags are sca=
nned, instead? Then the user will tailor their input to find the one or the=
 other.<br></div><div><br></div><div>If I understand you correctly, that&#3=
9;s also what I try to do -- each tagged command in the tags file is search=
ed by the name of the tag, which in these cases will either start with the =
escape char or not.=C2=A0 Looking at the biblatex snippet, if you come acro=
ss \csuse{blx@opt@uniquename@false} somewhere in a file, and you want to se=
e what the definition is, you can&#39;t know apriori how it was defined, wi=
th \def or with \csdef.=C2=A0 This snippet above mixes both styles, and I h=
oped that a user would be allowed to choose whether to search for both styl=
es without necessarily having to try both forms of the string in separate s=
earches.=C2=A0 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-nami=
ng styles separate.</div><div><br></div><div>The simplest fix is to remove =
the escape char from all tag names, which I suggest to users of ctags in so=
me commented-out code in etags.c. This does lose the ability to differentia=
te \def&#39;ed commands and \csdef&#39;d ones, especially as in some circum=
stances they can have the same name.=C2=A0 I&#39;m not sure how great a los=
s that is, on the other hand.=C2=A0 Is that what you had in mind?<br></div>=
<div><br></div>&gt; Or if we want more fuzzier matching, perhaps creating m=
ode-specific values of etags-xref-find-definitions-tag-order could help.<br=
><div><div><br></div><div>Yeah, you&#39;re right, I&#39;m pretty sure I cou=
ld use a buffer-local value of that variable to get xref-find-definitions t=
o do the fuzzy matching I&#39;m after.=C2=A0 Does the discussion above at a=
ll help to convince you that there are other issues that might still requir=
e a new backend?</div><div><br></div><div>David.<br></div></div></div>

--000000000000cf132205d89ce09f--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 21 Feb 2022 23:56:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 21 18:56:16 2022
Received: from localhost ([127.0.0.1]:39451 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nMIXQ-0006RY-Ak
	for submit <at> debbugs.gnu.org; Mon, 21 Feb 2022 18:56:16 -0500
Received: from mail-wr1-f50.google.com ([209.85.221.50]:37488)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1nMIXO-0006RH-Q6
 for 53749 <at> debbugs.gnu.org; Mon, 21 Feb 2022 18:56:15 -0500
Received: by mail-wr1-f50.google.com with SMTP id d28so1922916wra.4
 for <53749 <at> debbugs.gnu.org>; Mon, 21 Feb 2022 15:56:14 -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=voa8vLbt/1s1nbhtugRyLqihym+kFeb4bt3qDFoXWKg=;
 b=HSAfbWP8DISp96/EhXq77Fk3svQtxBGkxW0vaWOdpPKxYQMyc2Rx0Rs5ILtLn9TeWQ
 EPTs5VDfkRPQxYurNtFxnOzmOh5r2g2PcFczmL2/yrqJ7thUipD9BldKZdMaXyAD5mtd
 4AtHV+ub4gXUJTcmycUhiRXE616KDe4V2g8x2ZaAB+byD/YFcOK4P2AQAULuJxtYAM4s
 guLnaS0hTrBQrE8Sdc/buY2Y5XelOghg+ybJ6GQegwTdAuqiIm0C7c9IZGZbPKxPfIqq
 qGyELnqSUSrSe7hyAYyTUKBKyoEFWhj9+3+Ui2FPKDaYzUDbACI0NZfAR8OKtpXC9BGl
 nonw==
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=voa8vLbt/1s1nbhtugRyLqihym+kFeb4bt3qDFoXWKg=;
 b=iUTGJk8spuV0BS6RAJujD6xeIUWRm2SnOGMLERzzo+i2gvfpHSnpd0rk4QMnKdq7lW
 Jv/fuU0RzaBi3eWbGhbbtiGEqKydc7Jp+OknJhTKk22iuFPHmBEFx7R0U45lRGPtlXwL
 vgmLQGbaTpvRaVHiN/r+oERgORFRvJ6FGCdEsxfTfTgZOSgJMe1+WxrxNdXEsf/7n7Q+
 LazJFgQC/INvfagsBgoaGaqsDqo3h+AY/JSXxF820s25MsC1KOmIQWvEo3jzNF6IlZKN
 ODkXhZN/xN0Gpyt+92ZMFOjEwuWX3O4OnnIZ8rTcfes0r9NQf03aaBDzYybwpxT1c59m
 aPhw==
X-Gm-Message-State: AOAM530MTcVeSLqHUu+5DAwmT9MODrglWk/u7umBV3Dmncy4rcgvg0Hf
 rg1spvEB8m9VDgUxZ2WhOkU=
X-Google-Smtp-Source: ABdhPJzXnFuZYKVsk7ubjkb3rCjvQvTbQ2+/v+1egOCqnZsAPkjZWjYE00McuMqYmm3BxzHJLRthCA==
X-Received: by 2002:a5d:5986:0:b0:1ea:75c6:3d0a with SMTP id
 n6-20020a5d5986000000b001ea75c63d0amr2771442wri.166.1645487769184; 
 Mon, 21 Feb 2022 15:56:09 -0800 (PST)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id q76sm795098wme.1.2022.02.21.15.56.07
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 21 Feb 2022 15:56:08 -0800 (PST)
Message-ID: <2f41ba40-9c3f-ac65-ef0d-300bd11c4867@HIDDEN>
Date: Tue, 22 Feb 2022 01:56:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
Content-Language: en-US
To: David Fussner <dfussner@HIDDEN>
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <1de34060-e93b-0a42-fff5-20e283abe0dc@HIDDEN>
 <CADF+RthLfZVgu72wnPXf2=w-gnKZT+4eWR_kmDVMnFvBY8f1XQ@HIDDEN>
 <CADF+Rtho+2qOpGB6hn-Cpyx4qrUJd9c3+wAxsGtySi75pxzbsQ@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <CADF+Rtho+2qOpGB6hn-Cpyx4qrUJd9c3+wAxsGtySi75pxzbsQ@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

On 21.02.2022 19:28, David Fussner wrote:
> 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.

Sorry, I have very little familiarity with TeX.

Do you have a step-by-step scenario? Perhaps using one of the .texi 
manuals already existing in the repo?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 21 Feb 2022 23:55:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 21 18:55:27 2022
Received: from localhost ([127.0.0.1]:39446 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nMIWd-0006Pv-0c
	for submit <at> debbugs.gnu.org; Mon, 21 Feb 2022 18:55:27 -0500
Received: from mail-wr1-f41.google.com ([209.85.221.41]:35429)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1nMIWb-0006Pi-Nh
 for 53749 <at> debbugs.gnu.org; Mon, 21 Feb 2022 18:55:26 -0500
Received: by mail-wr1-f41.google.com with SMTP id v12so29726944wrv.2
 for <53749 <at> debbugs.gnu.org>; Mon, 21 Feb 2022 15:55: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=B7te4GuvmMyfYys9xDt9q3fBa9U0/nQRVKJFMFpgaJA=;
 b=ThdX5Vs1+f96p+jUhnaLMHURcGC6BDnHapbsk7OrvZCuwjD1LnzX1G0JJ/xxtgTDaT
 4obiYYgKBFuX3+UvASPy/vrqiWQIbkzq71cE8EXI27lp+Bx+3CywJgg/HYzTIAwsWpFF
 xFtARrjaF5xkoYXgRIJWA6Uj4kFjUwcmYTzFYG/VUdloYb1X+ufBokstMZdoP6OI3RQO
 kxD+72gxculgR2NCrJBcP3gCHnLn6TZcwKuWQk+KNESRPwrfoTYMvy8X9LVOuBCG5qf+
 ySjHGcxhTO68EFoa6PAaQK9qkAgHvz6Jh6dktjRhRC0Cjad9St1gOHNU8rBEDR+k2Iye
 K3sA==
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=B7te4GuvmMyfYys9xDt9q3fBa9U0/nQRVKJFMFpgaJA=;
 b=Q0X2S1D5ipC+DRTD8eX8p0lyVhNcgugQUJ/f76YWROVdsvdTtbw4/WnJLwAygEcI/E
 h9L2gbamV3VlAJ6x3Kj1yC4OWzlJu2XM22Tjq8nfXCCUFtzR03YsewC3X7C/Dotu6xcj
 XtjrIiskQI4Sf4PSgWhK0j0V49rzhJ9wA9p+FOSfLvamIb45fm4WqTdz3QZSpE/Nmni9
 o2/oWQluZ293YE8jRI7FYNddX/KEMZgFbtYlkAY6HrvofDNVnlGU+5ciubCYx4L9tpz5
 fkE5K4kEJOa7HhfLiGo25hwfR2iSVpxzpTgOmvPnoZZoizzI6Z79RXa1mtN4RptRA0Yk
 F/vw==
X-Gm-Message-State: AOAM533FxLWMPKJ177iyF36D7WrcSQl1rym6W5aIKDdLw661Y8d0WqpU
 nUtH6q9QacdCZ3eNwF+DZ0U=
X-Google-Smtp-Source: ABdhPJyK7DNMvOKKQoHFFmTdMfiWUCrT8w6+8oZaIYVjqvdl42rpcPPQb7DVd95Pg373zlUXo+o0xA==
X-Received: by 2002:adf:ea4f:0:b0:1e7:447d:2111 with SMTP id
 j15-20020adfea4f000000b001e7447d2111mr17588933wrn.66.1645487719607; 
 Mon, 21 Feb 2022 15:55:19 -0800 (PST)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id w18sm34127613wrl.62.2022.02.21.15.55.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 21 Feb 2022 15:55:18 -0800 (PST)
Message-ID: <a4262804-f70a-a845-4b1a-fadcbba7444c@HIDDEN>
Date: Tue, 22 Feb 2022 01:55:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
Content-Language: en-US
To: David Fussner <dfussner@HIDDEN>
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <1de34060-e93b-0a42-fff5-20e283abe0dc@HIDDEN>
 <CADF+RthLfZVgu72wnPXf2=w-gnKZT+4eWR_kmDVMnFvBY8f1XQ@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <CADF+RthLfZVgu72wnPXf2=w-gnKZT+4eWR_kmDVMnFvBY8f1XQ@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

On 21.02.2022 11:48, David Fussner wrote:
> 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.

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.

> 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.

Could those be be disambiguated when the tags are scanned, instead? Then 
the user will tailor their input to find the one or the other.

Or if we want more fuzzier matching, perhaps creating mode-specific 
values of etags-xref-find-definitions-tag-order could help.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 21 Feb 2022 17:28:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 21 12:28:53 2022
Received: from localhost ([127.0.0.1]:38889 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nMCUW-00044u-MC
	for submit <at> debbugs.gnu.org; Mon, 21 Feb 2022 12:28:53 -0500
Received: from mail-qk1-f182.google.com ([209.85.222.182]:36834)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dfussner@HIDDEN>) id 1nMCUV-00044j-8h
 for 53749 <at> debbugs.gnu.org; Mon, 21 Feb 2022 12:28:51 -0500
Received: by mail-qk1-f182.google.com with SMTP id g24so17621680qkl.3
 for <53749 <at> 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)
MIME-Version: 1.0
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <1de34060-e93b-0a42-fff5-20e283abe0dc@HIDDEN>
 <CADF+RthLfZVgu72wnPXf2=w-gnKZT+4eWR_kmDVMnFvBY8f1XQ@HIDDEN>
In-Reply-To: <CADF+RthLfZVgu72wnPXf2=w-gnKZT+4eWR_kmDVMnFvBY8f1XQ@HIDDEN>
From: David Fussner <dfussner@HIDDEN>
Date: Mon, 21 Feb 2022 17:28:32 +0000
Message-ID: <CADF+Rtho+2qOpGB6hn-Cpyx4qrUJd9c3+wAxsGtySi75pxzbsQ@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
To: Dmitry Gutov <dgutov@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

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 <dfussner@HIDDEN> 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 <dgutov@HIDDEN> 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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 21 Feb 2022 14:04:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 21 09:04:20 2022
Received: from localhost ([127.0.0.1]:35501 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nM9IZ-00033K-QD
	for submit <at> debbugs.gnu.org; Mon, 21 Feb 2022 09:04:20 -0500
Received: from mail-qv1-f43.google.com ([209.85.219.43]:45785)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dfussner@HIDDEN>) id 1nM9IX-00032w-9X
 for 53749 <at> debbugs.gnu.org; Mon, 21 Feb 2022 09:04:18 -0500
Received: by mail-qv1-f43.google.com with SMTP id c14so32255917qvl.12
 for <53749 <at> debbugs.gnu.org>; Mon, 21 Feb 2022 06:04:17 -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=tbA+9gMpO2xrFfW5c0c6cehf9bQbx7IHqA53ka/w0MQ=;
 b=p7Blm+hLznAjpaQuxIgRD/WNwzk5CLgLebBhVB7FjPXxqKxRIqJw1rmKjk8QFPU8FZ
 LjgKIgduXEOVHDcPcf/qh3NY6VGqNI07/TZDfJaVI4PpsgJktZXc5XiTAyCoGc9rHzHh
 zYJ2Pc7apUhYCeDGCLbslQo94xgTRkM5LJ8TlYSiomwV4H6lVCPhW7+cijvIMyncJjzr
 btYzK00jehPTuNkwN3Mo0QkfqMNSPoJTeDDQut9OwLwIXUoVCdPszwcxubK4EHZz7P5g
 ttyursOkQR2SVddtEWI+S9Gi0R0cSRbjyXEfrQDnrc+UNs/VwGLs0Wg0RXddjMFGPJVp
 lhTg==
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=tbA+9gMpO2xrFfW5c0c6cehf9bQbx7IHqA53ka/w0MQ=;
 b=C71xhIm4y5c58lldw449/Wahoo9TWHIECT7kO3ZtoavlEkR9s+xcAGrcZAiZnyDZac
 SPMB+YwJcxGKFr7gJBlhPyvHKHdZ+X6AqN5j8xoJF1hZ9QNg6Xf82gJKHBus/eBbuzah
 D7mQKGEa/+fYkTT/fPCsQDBMRmzUJc/NsG4JUr1mETUrNP7orsNdcXgKZn8WBFTJyMpu
 JQDry1d/W82QQsvZnkV0WmFpSEg1FbW1MG5fqbUl0AeSk2//D+dYpHTWjJQGmq8dF0i9
 fRsQwAwRboOPUwpuNvMfNbAVA3pbSbF6ibIiLzRn7OkCuZSMv8mCyjwpxoeQYLYF5Fsu
 aBrg==
X-Gm-Message-State: AOAM533HVT9Kst0vuW9qyPeGKig+qjWjUMkGZml4/VB7RQahQqBlFlX7
 uOMKkvyRXp2QrCUmgtmsxi155AK4xaD/RkHL3JyydkDypVKVxw==
X-Google-Smtp-Source: ABdhPJwvEznhZTsE6flTKk4Qk/5+X7NU+Srv3exT6qGoXZsdE3Ge1fDd4rm5Y2Vh3ccncvZ8Z40uAq03JOpSg+KjBvc=
X-Received: by 2002:a05:622a:64b:b0:2cf:1716:2344 with SMTP id
 a11-20020a05622a064b00b002cf17162344mr18167334qtb.635.1645452251686; Mon, 21
 Feb 2022 06:04:11 -0800 (PST)
MIME-Version: 1.0
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <86ilt84ct3.fsf@HIDDEN>
In-Reply-To: <86ilt84ct3.fsf@HIDDEN>
From: David Fussner <dfussner@HIDDEN>
Date: Mon, 21 Feb 2022 14:03:59 +0000
Message-ID: <CADF+Rtisx9fMC8eGLdXZ+YVfycXgNOkyX59cROjmxNj7hTeQTw@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
To: Arash Esbati <arash@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org, "David Fussner via Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Arash,

Thank you for the list!  I had fully intended to add the new LaTeX 3
commands but managed somehow to forget.  If you see anything else I've
omitted please let me know.

David.

On Mon, 21 Feb 2022 at 12:36, Arash Esbati <arash@HIDDEN> wrote:
>
> David Fussner via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs@HIDDEN> writes:
>
> > diff --git a/lib-src/etags.c b/lib-src/etags.c
> > index aa5bc8839d..e5269aa456 100644
> > --- a/lib-src/etags.c
> > +++ b/lib-src/etags.c
> > [...]
> >  /* Default set of control sequences to put into TEX_toktab.
> > -   The value of environment var TEXTAGS is prepended to this.  */
> > +   The value of environment var TEXTAGS is prepended to this.
> > +   (2021) Add variants of '\def', some additional LaTeX commands,
> > +   and common variants from the 'etoolbox' package.  Also, add
> > +   starred variants of the commands if they exist.  Starred
> > +   variants need to appear before their unstarred versions. */
> >  static const char *TEX_defenv = "\
> > -:chapter:section:subsection:subsubsection:eqno:label:ref:cite:bibitem\
> > -:part:appendix:entry:index:def\
> > -:newcommand:renewcommand:newenvironment:renewenvironment";
> > +:chapter*:section*:subsection*:subsubsection*:part*:label:ref\
> > +:chapter:section:subsection:subsubsection:eqno:cite:bibitem\
> > +:part:appendix:entry:index:def:edef:gdef:xdef:newcommand*:newcommand\
> > +:renewcommand*:renewcommand:newenvironment*:newenvironment\
> > +:renewenvironment*:renewenvironment:DeclareRobustCommand*\
> > +:DeclareRobustCommand:renewrobustcmd*:renewrobustcmd:newrobustcmd*\
> > +:newrobustcmd:let:csdef:csedef:csgdef:csxdef:csletcs:cslet";
>
> Hi David,
>
> thanks for looking into this.  While you're at it, can you also please
> add support for the former xparse \newcommand variants which are now
> (now is October 2020) part of LaTeX kernel, namely:
>
> \NewDocumentCommand
> \RenewDocumentCommand
> \ProvideDocumentCommand
> \DeclareDocumentCommand
> \NewDocumentEnvironment
> \RenewDocumentEnvironment
> \ProvideDocumentEnvironment
> \DeclareDocumentEnvironment
> \NewExpandableDocumentCommand
> \RenewExpandableDocumentCommand
> \ProvideExpandableDocumentCommand
> \DeclareExpandableDocumentCommand
>
> TIA.  Best, Arash




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 21 Feb 2022 14:04:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 21 09:04:19 2022
Received: from localhost ([127.0.0.1]:35499 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nM9IZ-00033I-Ft
	for submit <at> debbugs.gnu.org; Mon, 21 Feb 2022 09:04:19 -0500
Received: from lists.gnu.org ([209.51.188.17]:44104)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dfussner@HIDDEN>) id 1nM9IX-000333-B9
 for submit <at> debbugs.gnu.org; Mon, 21 Feb 2022 09:04:17 -0500
Received: from eggs.gnu.org ([209.51.188.92]:49238)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <dfussner@HIDDEN>)
 id 1nM9IX-00064B-06
 for bug-gnu-emacs@HIDDEN; Mon, 21 Feb 2022 09:04:17 -0500
Received: from [2607:f8b0:4864:20::f31] (port=46746
 helo=mail-qv1-xf31.google.com)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <dfussner@HIDDEN>)
 id 1nM9IU-00069q-U7; Mon, 21 Feb 2022 09:04:16 -0500
Received: by mail-qv1-xf31.google.com with SMTP id n6so32215638qvk.13;
 Mon, 21 Feb 2022 06:04:12 -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=tbA+9gMpO2xrFfW5c0c6cehf9bQbx7IHqA53ka/w0MQ=;
 b=p7Blm+hLznAjpaQuxIgRD/WNwzk5CLgLebBhVB7FjPXxqKxRIqJw1rmKjk8QFPU8FZ
 LjgKIgduXEOVHDcPcf/qh3NY6VGqNI07/TZDfJaVI4PpsgJktZXc5XiTAyCoGc9rHzHh
 zYJ2Pc7apUhYCeDGCLbslQo94xgTRkM5LJ8TlYSiomwV4H6lVCPhW7+cijvIMyncJjzr
 btYzK00jehPTuNkwN3Mo0QkfqMNSPoJTeDDQut9OwLwIXUoVCdPszwcxubK4EHZz7P5g
 ttyursOkQR2SVddtEWI+S9Gi0R0cSRbjyXEfrQDnrc+UNs/VwGLs0Wg0RXddjMFGPJVp
 lhTg==
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=tbA+9gMpO2xrFfW5c0c6cehf9bQbx7IHqA53ka/w0MQ=;
 b=cUzU+h/SCdTX7j6918X/bR90H4pF4N8Ss7bFo2AWlvVZy7vxd3Kj40aSKB17SCQb81
 q3gX6DrPFwCWrKpBHP0xYcv0YWX+uXLICHcFGaVPF/3J3+fUdNOxlJAoeKemPgXCmUZ2
 74gRnWV2wMmXJjGzsE0EjVRLOKiJo7YRgWMq08BsRgmh9iDlACl99uZfVDpM6TYYCudF
 +edDblR5POnlVV8YD0An/6NZ49l4sEFJlzHJEWtGbLW+5mSLnxsJXuSJp3pQ7jFNxrjt
 ga/2Y+MtG/yVep+CffLmV5GOB6CQuB3iw4eXwa7p3HhrXQ7caaNs9gb/p4U/sIZq+9V4
 jP+g==
X-Gm-Message-State: AOAM533YqJz/vGxTwrEeAOGiGXwwwVdBk3q4vfesq0XjO64tqsOhpGzv
 KxQsojAiS137UmoNdvN2PFtGata5zNzE2iTv49WU0hIAbaLv8w==
X-Google-Smtp-Source: ABdhPJwvEznhZTsE6flTKk4Qk/5+X7NU+Srv3exT6qGoXZsdE3Ge1fDd4rm5Y2Vh3ccncvZ8Z40uAq03JOpSg+KjBvc=
X-Received: by 2002:a05:622a:64b:b0:2cf:1716:2344 with SMTP id
 a11-20020a05622a064b00b002cf17162344mr18167334qtb.635.1645452251686; Mon, 21
 Feb 2022 06:04:11 -0800 (PST)
MIME-Version: 1.0
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <86ilt84ct3.fsf@HIDDEN>
In-Reply-To: <86ilt84ct3.fsf@HIDDEN>
From: David Fussner <dfussner@HIDDEN>
Date: Mon, 21 Feb 2022 14:03:59 +0000
Message-ID: <CADF+Rtisx9fMC8eGLdXZ+YVfycXgNOkyX59cROjmxNj7hTeQTw@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
To: Arash Esbati <arash@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::f31
 (failed)
Received-SPF: pass client-ip=2607:f8b0:4864:20::f31;
 envelope-from=dfussner@HIDDEN; helo=mail-qv1-xf31.google.com
X-Spam_score_int: -6
X-Spam_score: -0.7
X-Spam_bar: /
X-Spam_report: (-0.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 PDS_HP_HELO_NORDNS=0.659, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
Cc: 53749 <at> debbugs.gnu.org, "David Fussner via Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

Hi Arash,

Thank you for the list!  I had fully intended to add the new LaTeX 3
commands but managed somehow to forget.  If you see anything else I've
omitted please let me know.

David.

On Mon, 21 Feb 2022 at 12:36, Arash Esbati <arash@HIDDEN> wrote:
>
> David Fussner via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs@HIDDEN> writes:
>
> > diff --git a/lib-src/etags.c b/lib-src/etags.c
> > index aa5bc8839d..e5269aa456 100644
> > --- a/lib-src/etags.c
> > +++ b/lib-src/etags.c
> > [...]
> >  /* Default set of control sequences to put into TEX_toktab.
> > -   The value of environment var TEXTAGS is prepended to this.  */
> > +   The value of environment var TEXTAGS is prepended to this.
> > +   (2021) Add variants of '\def', some additional LaTeX commands,
> > +   and common variants from the 'etoolbox' package.  Also, add
> > +   starred variants of the commands if they exist.  Starred
> > +   variants need to appear before their unstarred versions. */
> >  static const char *TEX_defenv = "\
> > -:chapter:section:subsection:subsubsection:eqno:label:ref:cite:bibitem\
> > -:part:appendix:entry:index:def\
> > -:newcommand:renewcommand:newenvironment:renewenvironment";
> > +:chapter*:section*:subsection*:subsubsection*:part*:label:ref\
> > +:chapter:section:subsection:subsubsection:eqno:cite:bibitem\
> > +:part:appendix:entry:index:def:edef:gdef:xdef:newcommand*:newcommand\
> > +:renewcommand*:renewcommand:newenvironment*:newenvironment\
> > +:renewenvironment*:renewenvironment:DeclareRobustCommand*\
> > +:DeclareRobustCommand:renewrobustcmd*:renewrobustcmd:newrobustcmd*\
> > +:newrobustcmd:let:csdef:csedef:csgdef:csxdef:csletcs:cslet";
>
> Hi David,
>
> thanks for looking into this.  While you're at it, can you also please
> add support for the former xparse \newcommand variants which are now
> (now is October 2020) part of LaTeX kernel, namely:
>
> \NewDocumentCommand
> \RenewDocumentCommand
> \ProvideDocumentCommand
> \DeclareDocumentCommand
> \NewDocumentEnvironment
> \RenewDocumentEnvironment
> \ProvideDocumentEnvironment
> \DeclareDocumentEnvironment
> \NewExpandableDocumentCommand
> \RenewExpandableDocumentCommand
> \ProvideExpandableDocumentCommand
> \DeclareExpandableDocumentCommand
>
> TIA.  Best, Arash




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 21 Feb 2022 12:37:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 21 07:37:04 2022
Received: from localhost ([127.0.0.1]:35294 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nM7w8-0006vy-8c
	for submit <at> debbugs.gnu.org; Mon, 21 Feb 2022 07:37:04 -0500
Received: from eggs.gnu.org ([209.51.188.92]:51370)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <arash@HIDDEN>) id 1nM7w7-0006vU-2S
 for 53749 <at> debbugs.gnu.org; Mon, 21 Feb 2022 07:37:03 -0500
Received: from [2001:470:142:3::e] (port=50428 helo=fencepost.gnu.org)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <arash@HIDDEN>)
 id 1nM7vn-0007PT-1W; Mon, 21 Feb 2022 07:36:56 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To:
 From; bh=mhuH+1DmCdoPLs2LlDHYFblYBIPzmkoyWqL8A2mLlYo=; b=OnbUAqKybC4ZIqAes/xG
 fdwQpXCC9T7doK5tukrgO6JOB0YWWafaIfVu2Wqn28DZhmfZhfKV3BTkd5HA8a3AuhnnYV8Yqw4w3
 PVAZUoDSvggUAQFt0xZ7+0berunKQdmrH3zv0CGySKABsAUiFczwPew4LxQHNnxhxhxKG8kfQEw/Y
 er/7BLV+th65kAQ0utjuEfRZQgmrw/mvKxtJO8UEyKTe+M82wwowmtDcJKfw4Eor6f7/ZVCCjIBtv
 RkMbc9Dn3AgYvbmVfHydqiN9rBQanLwa5YmzqKclbYKsRTjUzCoN7zNGEesZQGqzQNkH2wZrUtkFH
 jXgeJemn/3bYEA==;
Received: from p5b326363.dip0.t-ipconnect.de ([91.50.99.99]:59830 helo=MUTANT)
 by fencepost.gnu.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1)
 (envelope-from <arash@HIDDEN>)
 id 1nM7vl-0004Zi-32; Mon, 21 Feb 2022 07:36:42 -0500
From: Arash Esbati <arash@HIDDEN>
To: David Fussner via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
Date: Mon, 21 Feb 2022 13:35:52 +0100
In-Reply-To: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 (David Fussner via's message of "Thu, 3 Feb 2022 15:09:22 +0000")
Message-ID: <86ilt84ct3.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org, David Fussner <dfussner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

David Fussner via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@HIDDEN> writes:

> diff --git a/lib-src/etags.c b/lib-src/etags.c
> index aa5bc8839d..e5269aa456 100644
> --- a/lib-src/etags.c
> +++ b/lib-src/etags.c
> [...]
>  /* Default set of control sequences to put into TEX_toktab.
> -   The value of environment var TEXTAGS is prepended to this.  */
> +   The value of environment var TEXTAGS is prepended to this.
> +   (2021) Add variants of '\def', some additional LaTeX commands,
> +   and common variants from the 'etoolbox' package.  Also, add
> +   starred variants of the commands if they exist.  Starred
> +   variants need to appear before their unstarred versions. */
>  static const char *TEX_defenv = "\
> -:chapter:section:subsection:subsubsection:eqno:label:ref:cite:bibitem\
> -:part:appendix:entry:index:def\
> -:newcommand:renewcommand:newenvironment:renewenvironment";
> +:chapter*:section*:subsection*:subsubsection*:part*:label:ref\
> +:chapter:section:subsection:subsubsection:eqno:cite:bibitem\
> +:part:appendix:entry:index:def:edef:gdef:xdef:newcommand*:newcommand\
> +:renewcommand*:renewcommand:newenvironment*:newenvironment\
> +:renewenvironment*:renewenvironment:DeclareRobustCommand*\
> +:DeclareRobustCommand:renewrobustcmd*:renewrobustcmd:newrobustcmd*\
> +:newrobustcmd:let:csdef:csedef:csgdef:csxdef:csletcs:cslet";

Hi David,

thanks for looking into this.  While you're at it, can you also please
add support for the former xparse \newcommand variants which are now
(now is October 2020) part of LaTeX kernel, namely:

\NewDocumentCommand
\RenewDocumentCommand
\ProvideDocumentCommand
\DeclareDocumentCommand
\NewDocumentEnvironment
\RenewDocumentEnvironment
\ProvideDocumentEnvironment
\DeclareDocumentEnvironment
\NewExpandableDocumentCommand
\RenewExpandableDocumentCommand
\ProvideExpandableDocumentCommand
\DeclareExpandableDocumentCommand

TIA.  Best, Arash




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 21 Feb 2022 12:37:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 21 07:37:14 2022
Received: from localhost ([127.0.0.1]:35298 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nM7wI-0006wK-Hp
	for submit <at> debbugs.gnu.org; Mon, 21 Feb 2022 07:37:14 -0500
Received: from lists.gnu.org ([209.51.188.17]:44054)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <arash@HIDDEN>) id 1nM7w9-0006w6-Lx
 for submit <at> debbugs.gnu.org; Mon, 21 Feb 2022 07:37:05 -0500
Received: from eggs.gnu.org ([209.51.188.92]:58042)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <arash@HIDDEN>) id 1nM7w2-0002fv-4K
 for bug-gnu-emacs@HIDDEN; Mon, 21 Feb 2022 07:37:03 -0500
Received: from [2001:470:142:3::e] (port=50428 helo=fencepost.gnu.org)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <arash@HIDDEN>)
 id 1nM7vn-0007PT-1W; Mon, 21 Feb 2022 07:36:56 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To:
 From; bh=mhuH+1DmCdoPLs2LlDHYFblYBIPzmkoyWqL8A2mLlYo=; b=OnbUAqKybC4ZIqAes/xG
 fdwQpXCC9T7doK5tukrgO6JOB0YWWafaIfVu2Wqn28DZhmfZhfKV3BTkd5HA8a3AuhnnYV8Yqw4w3
 PVAZUoDSvggUAQFt0xZ7+0berunKQdmrH3zv0CGySKABsAUiFczwPew4LxQHNnxhxhxKG8kfQEw/Y
 er/7BLV+th65kAQ0utjuEfRZQgmrw/mvKxtJO8UEyKTe+M82wwowmtDcJKfw4Eor6f7/ZVCCjIBtv
 RkMbc9Dn3AgYvbmVfHydqiN9rBQanLwa5YmzqKclbYKsRTjUzCoN7zNGEesZQGqzQNkH2wZrUtkFH
 jXgeJemn/3bYEA==;
Received: from p5b326363.dip0.t-ipconnect.de ([91.50.99.99]:59830 helo=MUTANT)
 by fencepost.gnu.org with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1)
 (envelope-from <arash@HIDDEN>)
 id 1nM7vl-0004Zi-32; Mon, 21 Feb 2022 07:36:42 -0500
From: Arash Esbati <arash@HIDDEN>
To: David Fussner via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
Date: Mon, 21 Feb 2022 13:35:52 +0100
In-Reply-To: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 (David Fussner via's message of "Thu, 3 Feb 2022 15:09:22 +0000")
Message-ID: <86ilt84ct3.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: submit
Cc: 53749 <at> debbugs.gnu.org, David Fussner <dfussner@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

David Fussner via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@HIDDEN> writes:

> diff --git a/lib-src/etags.c b/lib-src/etags.c
> index aa5bc8839d..e5269aa456 100644
> --- a/lib-src/etags.c
> +++ b/lib-src/etags.c
> [...]
>  /* Default set of control sequences to put into TEX_toktab.
> -   The value of environment var TEXTAGS is prepended to this.  */
> +   The value of environment var TEXTAGS is prepended to this.
> +   (2021) Add variants of '\def', some additional LaTeX commands,
> +   and common variants from the 'etoolbox' package.  Also, add
> +   starred variants of the commands if they exist.  Starred
> +   variants need to appear before their unstarred versions. */
>  static const char *TEX_defenv = "\
> -:chapter:section:subsection:subsubsection:eqno:label:ref:cite:bibitem\
> -:part:appendix:entry:index:def\
> -:newcommand:renewcommand:newenvironment:renewenvironment";
> +:chapter*:section*:subsection*:subsubsection*:part*:label:ref\
> +:chapter:section:subsection:subsubsection:eqno:cite:bibitem\
> +:part:appendix:entry:index:def:edef:gdef:xdef:newcommand*:newcommand\
> +:renewcommand*:renewcommand:newenvironment*:newenvironment\
> +:renewenvironment*:renewenvironment:DeclareRobustCommand*\
> +:DeclareRobustCommand:renewrobustcmd*:renewrobustcmd:newrobustcmd*\
> +:newrobustcmd:let:csdef:csedef:csgdef:csxdef:csletcs:cslet";

Hi David,

thanks for looking into this.  While you're at it, can you also please
add support for the former xparse \newcommand variants which are now
(now is October 2020) part of LaTeX kernel, namely:

\NewDocumentCommand
\RenewDocumentCommand
\ProvideDocumentCommand
\DeclareDocumentCommand
\NewDocumentEnvironment
\RenewDocumentEnvironment
\ProvideDocumentEnvironment
\DeclareDocumentEnvironment
\NewExpandableDocumentCommand
\RenewExpandableDocumentCommand
\ProvideExpandableDocumentCommand
\DeclareExpandableDocumentCommand

TIA.  Best, Arash




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 21 Feb 2022 09:48:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 21 04:48:50 2022
Received: from localhost ([127.0.0.1]:35082 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nM5JK-0004I5-5o
	for submit <at> debbugs.gnu.org; Mon, 21 Feb 2022 04:48:50 -0500
Received: from mail-qv1-f53.google.com ([209.85.219.53]:46035)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dfussner@HIDDEN>) id 1nM5JI-0004Hl-Be
 for 53749 <at> debbugs.gnu.org; Mon, 21 Feb 2022 04:48:48 -0500
Received: by mail-qv1-f53.google.com with SMTP id c14so30666733qvl.12
 for <53749 <at> debbugs.gnu.org>; Mon, 21 Feb 2022 01:48:48 -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=I2hDIlzhuQa9wnxxeda3KakJlY/Clx5R1MusA5yU4R4=;
 b=MWBIoAm3edGHHgO/IgOxHeU1eQyGX4M7BGzcjwD4YYhxb/LjNt5LWSFmDUk69Y8sQJ
 EeFTZ+auiSzU7X1SHF70OVSpah9f+TKwfjUKd/ASgse3sVxMJDWTW6FIHZpZhFyGYxCD
 0nijgeL8gkLWiCRd36mMUKEEWN4LeGUElInEn/4At0/ulugXl8hU46Yxjt+nhtrhW5A+
 xufMDazRVgboYbtyRYzgnfbCLgpyk60C2IhRE2ed+x5Vr+oxwMo6/RP5nkgeLpPQtg79
 9cXKMzLubcG9Wyu66lVPKOH36Me9QEdQnPt4PMOxPkWDbc2Ak52KCy+1Qu+8YMizHt+6
 CSXw==
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=I2hDIlzhuQa9wnxxeda3KakJlY/Clx5R1MusA5yU4R4=;
 b=WJXaVtdE8syCv6zjdu2TmFxo43fbcJlVlBsGPBWLIBndhHlhRxd7GKihSDsgDJd/N/
 WNpsdnqR9WDAtnE6AXcfG82q/APkx4O5QFtpFdsTdtKChaui6sjgqhFZ/valFCrj5TB1
 IGn4FWjRkTic40tI9vFaUYmepa4+lROAnAsCE2XRwVZYzLtYrg4bC5e6xgOCT+XJ7Bzl
 KZZqw7OOZ5VchG1gMSBUQq0k6pJ8Bji9Mg8vxEGFw1VCr9FjjzCwSaaS4oHPrWMRklmV
 TnJMIXggUA6qe6c2zmL+phXYwya87KZdTHSYUseY6Mkv+/CPnyd2cNvQLy0DJizqa2co
 hgvw==
X-Gm-Message-State: AOAM532PSM/HSM1NIfmLGmUWNnKAZKWA1n3r6mn0jrl7buJWmM3qWlEh
 vn2csasdGxJfqUPRIEvuv81gtiZiHyx6XDOPOx0YtyRRL5m+Zg==
X-Google-Smtp-Source: ABdhPJy05b+mq+hgv21tkaFsmTC7wxpcWy3TGrDZtbJ3TXr2hgPaWgCIg6dV/via3YEQ3VM0aW4mqLMJ7iHW6SE5RuE=
X-Received: by 2002:a05:622a:1a16:b0:2de:37ad:25ef with SMTP id
 f22-20020a05622a1a1600b002de37ad25efmr1047861qtb.131.1645436922612; Mon, 21
 Feb 2022 01:48:42 -0800 (PST)
MIME-Version: 1.0
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
 <1de34060-e93b-0a42-fff5-20e283abe0dc@HIDDEN>
In-Reply-To: <1de34060-e93b-0a42-fff5-20e283abe0dc@HIDDEN>
From: David Fussner <dfussner@HIDDEN>
Date: Mon, 21 Feb 2022 09:48:30 +0000
Message-ID: <CADF+RthLfZVgu72wnPXf2=w-gnKZT+4eWR_kmDVMnFvBY8f1XQ@HIDDEN>
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
To: Dmitry Gutov <dgutov@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 53749
Cc: 53749 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

(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 <dgutov@HIDDEN> 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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at 53749 <at> debbugs.gnu.org:


Received: (at 53749) by debbugs.gnu.org; 21 Feb 2022 02:11:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 20 21:11:42 2022
Received: from localhost ([127.0.0.1]:34310 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nLyAw-0001yg-P5
	for submit <at> debbugs.gnu.org; Sun, 20 Feb 2022 21:11:42 -0500
Received: from mail-wm1-f48.google.com ([209.85.128.48]:43888)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1nLyAv-0001yU-CS
 for 53749 <at> debbugs.gnu.org; Sun, 20 Feb 2022 21:11:41 -0500
Received: by mail-wm1-f48.google.com with SMTP id
 x3-20020a05600c21c300b0037c01ad715bso10261130wmj.2
 for <53749 <at> debbugs.gnu.org>; Sun, 20 Feb 2022 18:11:41 -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:references:from:in-reply-to
 :content-transfer-encoding;
 bh=DgZf9jHyWjNoewxfGO8CZz72EJPzszfr9FsbqI51VII=;
 b=p0lljqaf8qHHTc8ZZ/cdlZnFAfcQyO30O4whgzKjVUxZddYuxIpd6kOgXPLVLYAH0m
 MojvrQ6eY8vTp+NgCqbZNTRGaY5w1t+Wvox9/XC8YINCdx3QNfDxYx4BNwPpArMohNXr
 guAQ+QWOE6pp4fVasRWB9TRaBw2E+SVZbUL7WVZOgaCI0WgJXeqRlgFGHEWEKtNGeaNj
 oJ2T3Anj7BFz/eE4RmuPjbai6aGl2ld6stF9gGkiXCcoNeXkF7dBZYkkXutnzrdxw6M2
 K/90uH/0fVAFogRN1fzTfJyhzQj8/fO4+AIM66XGHFzWwgJJl5NW6chZEQ910dEBT9dy
 5nDA==
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:references:from:in-reply-to
 :content-transfer-encoding;
 bh=DgZf9jHyWjNoewxfGO8CZz72EJPzszfr9FsbqI51VII=;
 b=CgWWTnveP6tzzTkHSNK9gsRbuccn/NY37Fh3zKvy6XnxVCHYBVIdysMOVA7SWIqF8l
 9fN4QRPYmYoRpVqfN/vHuC6FKDEwFDoRu56gbcn2uLcctr2LCMKjHUIEF/ZriK8mgbXV
 jh/eP4pxtifxzQkE5ZuDdE6iJv9785juPDlHwnWyihzymVU3UANN3cVNqo2rlVRy9lEk
 wCG88KzzgJoFpVqo0VQrAimByS/kngXju4KVUBJQG40vBdQQjrX3uj5XnzxAfhZONhLA
 CWC/Xaa3Tash2KhxScCFg0FwI4agjevgPgYhMoBJGftJjZhnl78VdiLQ1XqRxDcgZkOP
 cvTA==
X-Gm-Message-State: AOAM533U+zaX4OBGgcARIZFysbmLD9lV+PGYXprsyoWnlbEc/D0HU523
 zvLZ1LWB2Gce7LJL0hSECIA=
X-Google-Smtp-Source: ABdhPJySwqqMKFcr7Ef26Hsvk2kt6+/ilR/5UYkTs+o2U/d6HKl9mIqDY8j/r+oWHolYIMVJnzK3sQ==
X-Received: by 2002:a05:600c:1d28:b0:37c:a9d:d39f with SMTP id
 l40-20020a05600c1d2800b0037c0a9dd39fmr15930073wms.172.1645409495378; 
 Sun, 20 Feb 2022 18:11:35 -0800 (PST)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id e4sm28225666wrp.25.2022.02.20.18.11.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 20 Feb 2022 18:11:35 -0800 (PST)
Message-ID: <1de34060-e93b-0a42-fff5-20e283abe0dc@HIDDEN>
Date: Mon, 21 Feb 2022 04:11:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers
Content-Language: en-US
To: David Fussner <dfussner@HIDDEN>, 53749 <at> debbugs.gnu.org
References: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 53749
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 3 Feb 2022 15:09:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 03 10:09:52 2022
Received: from localhost ([127.0.0.1]:57397 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nFdk7-0004gF-99
	for submit <at> debbugs.gnu.org; Thu, 03 Feb 2022 10:09:52 -0500
Received: from lists.gnu.org ([209.51.188.17]:35482)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dfussner@HIDDEN>) id 1nFdk5-0004g6-4w
 for submit <at> debbugs.gnu.org; Thu, 03 Feb 2022 10:09:50 -0500
Received: from eggs.gnu.org ([209.51.188.92]:45818)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <dfussner@HIDDEN>)
 id 1nFdk2-0000BS-QL
 for bug-gnu-emacs@HIDDEN; Thu, 03 Feb 2022 10:09:47 -0500
Received: from [2607:f8b0:4864:20::830] (port=43865
 helo=mail-qt1-x830.google.com)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <dfussner@HIDDEN>)
 id 1nFdjz-0004YM-Po
 for bug-gnu-emacs@HIDDEN; Thu, 03 Feb 2022 10:09:46 -0500
Received: by mail-qt1-x830.google.com with SMTP id x5so2489138qtw.10
 for <bug-gnu-emacs@HIDDEN>; Thu, 03 Feb 2022 07:09:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=googlemail.com; s=20210112;
 h=mime-version:from:date:message-id:subject:to;
 bh=FG58FpWqX5dqOaMqBqtIR1QCq9fb4hO9MKBH3GP0bR4=;
 b=NRzGguuk/ZyJH4rJ2/nfMQzmQ6YLYgukEOKO3yB1KxG90hF10tz19FsHIopKvDNzJY
 HnQriD4xkKk0HcEi76vX5Ao47bs/tywfMHAXP6poZgTpOeJ/39GlI1GRLG5U0TNClSuq
 ozw0RG03wLXtS227ruuSE3rBVigU2ffh2946+v+299WJQjGRaMoCmVFlK8mJbZcqO1bP
 HsLbAXw65hcKxcJXvjrIXyMQ/IxjIVXx6y1uaQJ9GI7uw+S10FViEt+BbwImvTURGZSg
 XaR1V4UgPJ0bP0BIIlhCQTOXvoL3g68aip5XAX3sC3suXOfCusDcCEmEg9m3gdX+/8Tv
 GhBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=FG58FpWqX5dqOaMqBqtIR1QCq9fb4hO9MKBH3GP0bR4=;
 b=8AD2lFppATIHuBTEdX0fojg0mxRRG1yr4Il+yQTx9D9BookCy+U7+Ak9yGbCrcYK06
 G4iZdOB5skfVe8BV8USPv8E9urLv6HFpwgWcaHEcuEjk0GeEKH+nNS5CdGVEbZw3KMmz
 0Mbs71vEi0E6nRE27mLfSWLfZYhjtW15+z71l4SlUlgv8fwQazm0VlNRZWtxV8RYHITT
 Ejp6F41eYeE0EQMco0KkdaT1xKh+Ufe6sVeUbtTHjKI8wUjQaqibg9LXZ01JfaKWs5G4
 HGqBzNUWTJAldAqd/zXEtG2iBeoxppbKIU8KrR5oA4avyRuEVJzoxe3jIRtRZrNmg17m
 GqdQ==
X-Gm-Message-State: AOAM532VugSzcTg6SA4IrTvrrq697Da1jvoim1aU9BISnwO8nkEQHzIq
 C640Q17/1nNkxoWxaUxRbKd2itCNlhgkbiLDcZU5RoUhVm+Z0g==
X-Google-Smtp-Source: ABdhPJx2bRjGnxK/hgJ5j4BExtY9yptBRG/9Aku6LaZ3SPWtg204KzR39l48STM5GpgQTFQ9pUOJs8WLin35Qxsuo2E=
X-Received: by 2002:a05:620a:2a07:: with SMTP id
 o7mr23177669qkp.274.1643900977699; 
 Thu, 03 Feb 2022 07:09:37 -0800 (PST)
MIME-Version: 1.0
From: David Fussner <dfussner@HIDDEN>
Date: Thu, 3 Feb 2022 15:09:22 +0000
Message-ID: <CADF+RtgWCLKQGwgdTNWmgesbcwq8iBxChoN8FqMOg95Ai3CYTA@HIDDEN>
Subject: 29.0.50; [PATCH] Xref backend for TeX buffers
To: bug-gnu-emacs@HIDDEN
Content-Type: multipart/mixed; boundary="000000000000d28fd905d71e8534"
X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::830
 (failed)
Received-SPF: pass client-ip=2607:f8b0:4864:20::830;
 envelope-from=dfussner@HIDDEN; helo=mail-qt1-x830.google.com
X-Spam_score_int: -12
X-Spam_score: -1.3
X-Spam_bar: -
X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.2 (/)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

--000000000000d28fd905d71e8534
Content-Type: multipart/alternative; boundary="000000000000d28fd805d71e8532"

--000000000000d28fd805d71e8532
Content-Type: text/plain; charset="UTF-8"

I've recently been trying to use xref commands with a tags table in a
TeX repository, and many of the results are sub-optimal.  This is a
known issue -- within living memory there have been at least two
discussions related to it on help-gnu-emacs:

https://lists.gnu.org/archive/html/help-gnu-emacs/2018-06/msg00126.html
https://lists.gnu.org/archive/html/help-gnu-emacs/2021-07/msg00436.html

Neither discussion resulted in any code, at least not that I can find,
and the issues mentioned there remain.  For example,
xref-find-definitions on, say, '\mycommand' returns

No definitions found for: mycommand.

(The absence of the escape char in the search string makes the search
fail, as the tag name in the table will be '\mycommand'.)

Similarly, any xref command on 'my:citekey' will only search by default
for the half of the symbol under point, stopping at the colon.

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.

A few remarks:

1. The code should work as it stands both in the AUCTeX and the in-tree
modes.  The AUCTeX hooks I've included in the patch are provisional, as
I would want to discuss with them how they would want to handle it,
should the patch be accepted in some form.

2. Along the way I found some issues with how etags parses TeX files,
issues which affect the usefulness of the xref commands, so I've made
changes in etags.c as well.  When running the test suite for etags the
only diffs occurred in the TeX-related sections of the resulting tags
file, and location information in those sections was good.

3. The patch as it stands enables all the changes by default to give
what I judge to be the best out-of-the-box experience, but wiser heads
may well have other ideas.

4. If it looks like the patch will make it into Emacs in some form, I'm
going to need to assign copyright, so I'd appreciate help with getting
that started.

Thanks,

David.

--000000000000d28fd805d71e8532
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;ve recently been trying to use xref commands with a =
tags table in a<br>TeX repository, and many of the results are sub-optimal.=
=C2=A0 This is a<br>known issue -- within living memory there have been at =
least two<br>discussions related to it on help-gnu-emacs:<br><br><a href=3D=
"https://lists.gnu.org/archive/html/help-gnu-emacs/2018-06/msg00126.html">h=
ttps://lists.gnu.org/archive/html/help-gnu-emacs/2018-06/msg00126.html</a><=
br><a href=3D"https://lists.gnu.org/archive/html/help-gnu-emacs/2021-07/msg=
00436.html">https://lists.gnu.org/archive/html/help-gnu-emacs/2021-07/msg00=
436.html</a><br><br>Neither discussion resulted in any code, at least not t=
hat I can find,<br>and the issues mentioned there remain.=C2=A0 For example=
,<br>xref-find-definitions on, say, &#39;\mycommand&#39; returns<br><br>No =
definitions found for: mycommand.<br><br>(The absence of the escape char in=
 the search string makes the search<br>fail, as the tag name in the table w=
ill be &#39;\mycommand&#39;.)<br><br>Similarly, any xref command on &#39;my=
:citekey&#39; will only search by default<br>for the half of the symbol und=
er point, stopping at the colon.<br><br>There are many other behaviors that=
 are suboptimal, as well, so in the<br>end I wrote a new xref backend for T=
eX buffers (cloning large portions<br>of the default etags backend), and wo=
ndered whether it might be welcome<br>in GNU Emacs.<br><br>A few remarks:<b=
r><br>1. The code should work as it stands both in the AUCTeX and the in-tr=
ee<br>modes.=C2=A0 The AUCTeX hooks I&#39;ve included in the patch are prov=
isional, as<br>I would want to discuss with them how they would want to han=
dle it,<br>should the patch be accepted in some form.<br><br>2. Along the w=
ay I found some issues with how etags parses TeX files,<br>issues which aff=
ect the usefulness of the xref commands, so I&#39;ve made<br>changes in eta=
gs.c as well.=C2=A0 When running the test suite for etags the<br>only diffs=
 occurred in the TeX-related sections of the resulting tags<br>file, and lo=
cation information in those sections was good.<br><br>3. The patch as it st=
ands enables all the changes by default to give<br>what I judge to be the b=
est out-of-the-box experience, but wiser heads<br>may well have other ideas=
.<br><br>4. If it looks like the patch will make it into Emacs in some form=
, I&#39;m<br>going to need to assign copyright, so I&#39;d appreciate help =
with getting<br>that started.<br><br>Thanks,<br><br>David.</div>

--000000000000d28fd805d71e8532--

--000000000000d28fd905d71e8534
Content-Type: text/x-patch; charset="US-ASCII"; 
	name="0001-Provide-an-xref-backend-for-TeX-buffers.patch"
Content-Disposition: attachment; 
	filename="0001-Provide-an-xref-backend-for-TeX-buffers.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_kz7439kw0>
X-Attachment-Id: f_kz7439kw0

RnJvbSA5ZjViMjU0N2ZlZjU1OTdmOWM0MWUxYzQ2Zjk5NzQ2MDk1YTA4MzRjIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBEYXZpZCBGdXNzbmVyIDxkZnVzc25lckBnb29nbGVtYWlsLmNv
bT4KRGF0ZTogV2VkLCAyIEZlYiAyMDIyIDEzOjMxOjUxICswMDAwClN1YmplY3Q6IFtQQVRDSF0g
UHJvdmlkZSBhbiB4cmVmIGJhY2tlbmQgZm9yIFRlWCBidWZmZXJzCgoqIGxpYi1zcmMvZXRhZ3Mu
YyAoVGVYX2NvbW1hbmRzKTogSW1wcm92ZSBwYXJzaW5nIG9mIGNvbW1hbmRzIGluIFRlWApidWZm
ZXJzLgooVEVYX2RlZmVudik6IEV4cGFuZCBsaXN0IG9mIGNvbW1hbmRzIHRvIHRhZyBieSBkZWZh
dWx0IGluIFRlWApidWZmZXJzLgooVGVYX2hlbHApOgoqIGRvYy9lbWFjcy9tYWludGFpbmluZy50
ZXhpIChUYWcgU3ludGF4KTogRG9jdW1lbnQgbmV3IHRhZ2dlZApjb21tYW5kcy4KCiogbGlzcC90
ZXh0bW9kZXMvdGV4LW1vZGUuZWwgKHRleC0teHJlZi1iYWNrZW5kKTogTmV3IGZ1bmN0aW9uIHRv
IG5hbWUKeHJlZiBiYWNrZW5kLgoodGV4LWNvbW1vbi1pbml0aWFsaXphdGlvbik6IFNldCB1cCB4
cmVmIGJhY2tlbmQgZm9yIGluLXRyZWUgVGVYCm1vZGVzLgoodGV4LXNldC1hdWN0ZXgteHJlZi1i
YWNrZW5kKTogTmV3IGZ1bmN0aW9uIHRvIGRvIHRoZSBzYW1lIGZvciBBVUNUZVgKbW9kZXMuCih4
cmVmLWJhY2tlbmQtaWRlbnRpZmllci1hdC1wb2ludCkKKHhyZWYtYmFja2VuZC1pZGVudGlmaWVy
LWNvbXBsZXRpb24tdGFibGUpCih4cmVmLWJhY2tlbmQtaWRlbnRpZmllci1jb21wbGV0aW9uLWln
bm9yZS1jYXNlKQooeHJlZi1iYWNrZW5kLWRlZmluaXRpb25zLCB4cmVmLWJhY2tlbmQtYXByb3Bv
cykKKHhyZWYtYmFja2VuZC1yZWZlcmVuY2VzKTogTmV3IFRlWCBpbXBsZW1lbnRhdGlvbnMgb2Yg
dGhlIGdlbmVyaWMgeHJlZgpiYWNrZW5kIGZ1bmN0aW9ucy4KKHRleC14cmVmLWFwcm9wb3MtcmVn
ZXhwLCB0ZXgteHJlZi1yZWZlcmVuY2VzLWluLWRpcmVjdG9yeSk6IE5ldwpoZWxwZXIgZnVuY3Rp
b25zIGZvciBiYWNrZW5kLgoodGV4LXRoaW5nYXRwdC1tb2Rlcy1saXN0KTogTmV3IHZhci4KKHRl
eC10aGluZ2F0cHQtaXMtdGV4c3ltYm9sKTogTmV3IGRlZmN1c3RvbS4KKHRleC1zZXQtdGhpbmdh
dHB0LXN5bWJvbCk6IE5ldyBjb21tYW5kIHRvIGFwcGx5IHZhbHVlIG9mIHByZXZpb3VzCmJ1ZmZl
ci1sb2NhbGx5LgoodGV4LS1zeW1ib2wtb3ItdGV4c3ltYm9sKTogTmV3IGhlbHBlciBmdW5jdGlv
biBmb3IgcHJldmlvdXMuCih0ZXgtdGhpbmdhdHB0LS1iZWdpbm5pbmctb2YtdGV4c3ltYm9sKQoo
dGV4LXRoaW5nYXRwdC0tZW5kLW9mLXRleHN5bWJvbCk6IE5ldyBmdW5jdGlvbnMgdG8gZGVmaW5l
IHRleHN5bWJvbAoidGhpbmciIGZvciAndGhpbmctYXQtcG9pbnQnLgoodGV4LXRoaW5nYXRwdC1z
eW50YXgtdGFibGUsIHRleC1lc2NhcGUtY2hhcik6IE5ldyB2YXJzIHRvIGRvIHRoZQpzYW1lLgoo
dGV4LS10aGluZy1hdC1wb2ludCk6IE5ldyBmdW5jdGlvbiB0byByZXR1cm4gdGV4c3ltYm9sCid0
aGluZy1hdC1wb2ludCcuCih0ZXgtdGhpbmdhdHB0LWluY2x1ZGUtZXNjYXBlLCB0ZXgteHJlZi10
cnktYWx0ZXJuYXRlLWZvcm1zKTogTmV3CmRlZmN1c3RvbXMgdG8gcmVmaW5lIGJlaGF2aW9yIG9m
IHRoZSB4cmVmIGJhY2tlbmQuCih0ZXgtLWluY2x1ZGUtZXNjYXBlLXApOiBOZXcgZnVuY3Rpb24g
dG8gZG8gdGhlIHNhbWUuCi0tLQogZG9jL2VtYWNzL21haW50YWluaW5nLnRleGkgfCAgIDkgKy0K
IGxpYi1zcmMvZXRhZ3MuYyAgICAgICAgICAgIHwgIDgzICsrKysrKysrLS0KIGxpc3AvdGV4dG1v
ZGVzL3RleC1tb2RlLmVsIHwgMzMxICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysKIDMgZmlsZXMgY2hhbmdlZCwgNDExIGluc2VydGlvbnMoKyksIDEyIGRlbGV0aW9ucygtKQoK
ZGlmZiAtLWdpdCBhL2RvYy9lbWFjcy9tYWludGFpbmluZy50ZXhpIGIvZG9jL2VtYWNzL21haW50
YWluaW5nLnRleGkKaW5kZXggZWRjYzYwNzVmNy4uMWRlNDM1MjQ2ZSAxMDA2NDQKLS0tIGEvZG9j
L2VtYWNzL21haW50YWluaW5nLnRleGkKKysrIGIvZG9jL2VtYWNzL21haW50YWluaW5nLnRleGkK
QEAgLTI1NjUsOCArMjU2NSwxMyBAQCBUYWcgU3ludGF4CiBAY29kZXtcc2VjdGlvbn0sIEBjb2Rl
e1xzdWJzZWN0aW9ufSwgQGNvZGV7XHN1YnN1YnNlY3Rpb259LAogQGNvZGV7XGVxbm99LCBAY29k
ZXtcbGFiZWx9LCBAY29kZXtccmVmfSwgQGNvZGV7XGNpdGV9LAogQGNvZGV7XGJpYml0ZW19LCBA
Y29kZXtccGFydH0sIEBjb2Rle1xhcHBlbmRpeH0sIEBjb2Rle1xlbnRyeX0sCi1AY29kZXtcaW5k
ZXh9LCBAY29kZXtcZGVmfSwgQGNvZGV7XG5ld2NvbW1hbmR9LCBAY29kZXtccmVuZXdjb21tYW5k
fSwKLUBjb2Rle1xuZXdlbnZpcm9ubWVudH0gYW5kIEBjb2Rle1xyZW5ld2Vudmlyb25tZW50fSBh
cmUgdGFncy4KK0Bjb2Rle1xpbmRleH0sIEBjb2Rle1xkZWZ9LCBAY29kZXtcZWRlZn0sIEBjb2Rl
e1xnZGVmfSwgQGNvZGV7XHhkZWZ9LAorQGNvZGV7XG5ld2NvbW1hbmR9LCBAY29kZXtccmVuZXdj
b21tYW5kfSwgQGNvZGV7XG5ld2Vudmlyb25tZW50fSwKK0Bjb2Rle1xyZW5ld2Vudmlyb25tZW50
fSwgQGNvZGV7XERlY2xhcmVSb2J1c3RDb21tYW5kfSwKK0Bjb2Rle1xuZXdyb2J1c3RjbWR9LCBA
Y29kZXtccmVuZXdyb2J1c3RjbWR9LCBAY29kZXtcbGV0fSwKK0Bjb2Rle1xjc2RlZn0sIEBjb2Rl
e1xjc2VkZWZ9LCBAY29kZXtcY3NnZGVmfSwgQGNvZGV7XGNzeGRlZn0sCitAY29kZXtcY3NsZXRj
c30sIGFuZCBAY29kZXtcY3NsZXR9IGFyZSB0YWdzLiAgU28gdG9vIGFyZSB0aGUgYXJndW1lbnRz
CitvZiBhbnkgc3RhcnJlZCB2YXJpYW50cyBvZiB0aGVzZSBjb21tYW5kcywgd2hlbiBzdWNoIHZh
cmlhbnRzIGV4aXN0LgogCiBPdGhlciBjb21tYW5kcyBjYW4gbWFrZSB0YWdzIGFzIHdlbGwsIGlm
IHlvdSBzcGVjaWZ5IHRoZW0gaW4gdGhlCiBlbnZpcm9ubWVudCB2YXJpYWJsZSBAZW52e1RFWFRB
R1N9IGJlZm9yZSBpbnZva2luZyBAY29tbWFuZHtldGFnc30uICBUaGUKZGlmZiAtLWdpdCBhL2xp
Yi1zcmMvZXRhZ3MuYyBiL2xpYi1zcmMvZXRhZ3MuYwppbmRleCBhYTViYzg4MzlkLi5lNTI2OWFh
NDU2IDEwMDY0NAotLS0gYS9saWItc3JjL2V0YWdzLmMKKysrIGIvbGliLXNyYy9ldGFncy5jCkBA
IC03OTMsOCArNzkzLDEyIEBAICNkZWZpbmUgU1RESU4gMHgxMDAxCQkvKiByZXR1cm5lZCBieSBn
ZXRvcHRfbG9uZyBvbiAtLXBhcnNlLXN0ZGluICovCiAiSW4gTGFUZVggdGV4dCwgdGhlIGFyZ3Vt
ZW50IG9mIGFueSBvZiB0aGUgY29tbWFuZHMgJ1xcY2hhcHRlcicsXG5cCiAnXFxzZWN0aW9uJywg
J1xcc3Vic2VjdGlvbicsICdcXHN1YnN1YnNlY3Rpb24nLCAnXFxlcW5vJywgJ1xcbGFiZWwnLFxu
XAogJ1xccmVmJywgJ1xcY2l0ZScsICdcXGJpYml0ZW0nLCAnXFxwYXJ0JywgJ1xcYXBwZW5kaXgn
LCAnXFxlbnRyeScsXG5cCi0nXFxpbmRleCcsICdcXGRlZicsICdcXG5ld2NvbW1hbmQnLCAnXFxy
ZW5ld2NvbW1hbmQnLFxuXAotJ1xcbmV3ZW52aXJvbm1lbnQnIG9yICdcXHJlbmV3ZW52aXJvbm1l
bnQnIGlzIGEgdGFnLlxuXAorJ1xcaW5kZXgnLCAnXFxkZWYnLCAnXFxlZGVmJywgJ1xcZ2RlZics
ICdcXHhkZWYnLCAnXFxuZXdjb21tYW5kJyxcblwKKydcXHJlbmV3Y29tbWFuZCcsICdcXG5ld2Vu
dmlyb25tZW50JywgJ1xccmVuZXdlbnZpcm9ubWVudCcsXG5cCisnXFxEZWNsYXJlUm9idXN0Q29t
bWFuZCwgJ1xcbmV3cm9idXN0Y21kJywgJ1xccmVuZXdyb2J1c3RjbWQnLFxuXAorJ1xcbGV0Jywg
J1xcY3NkZWYnLCAnXFxjc2VkZWYnLCAnXFxjc2dkZWYnLCAnXFxjc3hkZWYnLCAnXFxjc2xldGNz
JyxcblwKK29yICdcXGNzbGV0JyBpcyBhIHRhZy4gIFNvIGlzIHRoZSBhcmd1bWVudCBvZiBhbnkg
b2YgdGhlIHN0YXJyZWRcblwKK3ZhcmlhbnRzIG9mIHRoZXNlIGNvbW1hbmRzLCB3aGVuIGEgc3Rh
cnJlZCB2YXJpYW50IGV4aXN0cy5cblwKIFxuXAogT3RoZXIgY29tbWFuZHMgY2FuIGJlIHNwZWNp
ZmllZCBieSBzZXR0aW5nIHRoZSBlbnZpcm9ubWVudCB2YXJpYWJsZVxuXAogJ1RFWFRBR1MnIHRv
IGEgY29sb24tc2VwYXJhdGVkIGxpc3QgbGlrZSwgZm9yIGV4YW1wbGUsXG5cCkBAIC01NjczLDEx
ICs1Njc3LDE5IEBAIFNjaGVtZV9mdW5jdGlvbnMgKEZJTEUgKmluZikKIHN0YXRpYyBsaW5lYnVm
ZmVyICpURVhfdG9rdGFiID0gTlVMTDsgLyogVGFibGUgd2l0aCB0YWcgdG9rZW5zICovCiAKIC8q
IERlZmF1bHQgc2V0IG9mIGNvbnRyb2wgc2VxdWVuY2VzIHRvIHB1dCBpbnRvIFRFWF90b2t0YWIu
Ci0gICBUaGUgdmFsdWUgb2YgZW52aXJvbm1lbnQgdmFyIFRFWFRBR1MgaXMgcHJlcGVuZGVkIHRv
IHRoaXMuICAqLworICAgVGhlIHZhbHVlIG9mIGVudmlyb25tZW50IHZhciBURVhUQUdTIGlzIHBy
ZXBlbmRlZCB0byB0aGlzLgorICAgKDIwMjEpIEFkZCB2YXJpYW50cyBvZiAnXGRlZicsIHNvbWUg
YWRkaXRpb25hbCBMYVRlWCBjb21tYW5kcywKKyAgIGFuZCBjb21tb24gdmFyaWFudHMgZnJvbSB0
aGUgJ2V0b29sYm94JyBwYWNrYWdlLiAgQWxzbywgYWRkCisgICBzdGFycmVkIHZhcmlhbnRzIG9m
IHRoZSBjb21tYW5kcyBpZiB0aGV5IGV4aXN0LiAgU3RhcnJlZAorICAgdmFyaWFudHMgbmVlZCB0
byBhcHBlYXIgYmVmb3JlIHRoZWlyIHVuc3RhcnJlZCB2ZXJzaW9ucy4gKi8KIHN0YXRpYyBjb25z
dCBjaGFyICpURVhfZGVmZW52ID0gIlwKLTpjaGFwdGVyOnNlY3Rpb246c3Vic2VjdGlvbjpzdWJz
dWJzZWN0aW9uOmVxbm86bGFiZWw6cmVmOmNpdGU6YmliaXRlbVwKLTpwYXJ0OmFwcGVuZGl4OmVu
dHJ5OmluZGV4OmRlZlwKLTpuZXdjb21tYW5kOnJlbmV3Y29tbWFuZDpuZXdlbnZpcm9ubWVudDpy
ZW5ld2Vudmlyb25tZW50IjsKKzpjaGFwdGVyKjpzZWN0aW9uKjpzdWJzZWN0aW9uKjpzdWJzdWJz
ZWN0aW9uKjpwYXJ0KjpsYWJlbDpyZWZcCis6Y2hhcHRlcjpzZWN0aW9uOnN1YnNlY3Rpb246c3Vi
c3Vic2VjdGlvbjplcW5vOmNpdGU6YmliaXRlbVwKKzpwYXJ0OmFwcGVuZGl4OmVudHJ5OmluZGV4
OmRlZjplZGVmOmdkZWY6eGRlZjpuZXdjb21tYW5kKjpuZXdjb21tYW5kXAorOnJlbmV3Y29tbWFu
ZCo6cmVuZXdjb21tYW5kOm5ld2Vudmlyb25tZW50KjpuZXdlbnZpcm9ubWVudFwKKzpyZW5ld2Vu
dmlyb25tZW50KjpyZW5ld2Vudmlyb25tZW50OkRlY2xhcmVSb2J1c3RDb21tYW5kKlwKKzpEZWNs
YXJlUm9idXN0Q29tbWFuZDpyZW5ld3JvYnVzdGNtZCo6cmVuZXdyb2J1c3RjbWQ6bmV3cm9idXN0
Y21kKlwKKzpuZXdyb2J1c3RjbWQ6bGV0OmNzZGVmOmNzZWRlZjpjc2dkZWY6Y3N4ZGVmOmNzbGV0
Y3M6Y3NsZXQiOwogCiBzdGF0aWMgdm9pZCBURVhfZGVjb2RlX2VudiAoY29uc3QgY2hhciAqLCBj
b25zdCBjaGFyICopOwogCkBAIC01NzM2LDE5ICs1NzQ4LDcwIEBAIFRlWF9jb21tYW5kcyAoRklM
RSAqaW5mKQogCSAgICAgIHsKIAkJY2hhciAqcDsKIAkJcHRyZGlmZl90IG5hbWVsZW4sIGxpbmVs
ZW47Ci0JCWJvb2wgb3BncnAgPSBmYWxzZTsKKwkJYm9vbCBvcGdycCA9IGZhbHNlLCBvbmVfZXNj
ID0gZmFsc2U7CiAKIAkJY3AgPSBza2lwX3NwYWNlcyAoY3AgKyBrZXktPmxlbik7CisJCS8qIFNr
aXAgdGhlIG9wdGlvbmFsIGFyZ3VtZW50cyB0byBjb21tYW5kcyBpbiB0aGUgdGFncyBsaXN0IHNv
CisJCSAgIHRoYXQgdGhlc2UgYXJndW1lbnRzIGRvbid0IGVuZCB1cCBhcyB0aGUgbmFtZSBvZiB0
aGUgdGFnLgorCQkgICBUaGUgbmFtZSB3aWxsIGluc3RlYWQgY29tZSBmcm9tIHRoZSBhcmd1bWVu
dCBpbiBjdXJseSBicmFjZXMKKwkJICAgdGhhdCBmb2xsb3dzIHRoZSBvcHRpb25hbCBvbmVzLiAg
Ki8KKwkJaWYgKCpjcCA9PSAnWycgfHwgKmNwID09ICcoJykKKwkJICB7CisJCSAgICB3aGlsZSAo
KmNwICE9IFRFWF9vcGdycCAmJiAqY3AgIT0gJ1wwJykKKwkJICAgICAgY3ArKzsKKwkJICB9CiAJ
CWlmICgqY3AgPT0gVEVYX29wZ3JwKQogCQkgIHsKIAkJICAgIG9wZ3JwID0gdHJ1ZTsKIAkJICAg
IGNwKys7CiAJCSAgfQorCQkvKiBKdW1waW5nIHRvIGEgVGVYIGNvbW1hbmQgZGVmaW5pdGlvbiBk
b2Vzbid0IHdvcmsgaW4gYXQKKwkJICAgbGVhc3Qgc29tZSBvZiB0aGUgZWRpdG9ycyB0aGF0IHVz
ZSBjdGFncy4gIENoYW5nZXMgaW4KKwkJICAgdGV4LW1vZGUuZWwgaW4gR05VIEVtYWNzIGFkZHJl
c3MgdGhlc2UgaXNzdWVzIGZvciBldGFnczsKKwkJICAgdW5jb21tZW50IHRoZSBmb2xsb3dpbmcg
Zml2ZSBsaW5lcyB0byBnZXQgYSBxdWljayAmIGRpcnR5CisJCSAgIGltcHJvdmVtZW50IGluIHBy
b2dyYW1zIHVzaW5nIGN0YWdzIGFzIHdlbGwsIHRob3VnaCBzb21lCisJCSAgIHBhcnRzIG9mIHRo
ZSBiZWhhdmlvciB3aWxsIHJlbWFpbiBzdWJvcHRpbWFsLiAgVGhlCisJCSAgIHVuZG9jdW1lbnRl
ZCBjdGFncyBvcHRpb24gJy0tbm8tZHVwbGljYXRlcycgbWF5IGhlbHAuICAqLworCisJCS8qIGlm
IChDVEFHUyAmJiAqY3AgPT0gVEVYX2VzYykgKi8KKwkJLyogICB7ICovCisJCS8qICAgICBjcCsr
OyAqLworCQkvKiAgICAgb25lX2VzYyA9IHRydWU7ICovCisJCS8qICAgfSAqLworCisJCS8qIEFk
ZCBvcHRpb25hbCBhcmd1bWVudCBicmFja2V0cyAnKCcgYW5kICdbJyBzbyB0aGF0IHRoZXNlCisJ
CSAgIGFyZ3VtZW50cyBkb24ndCBhcHBlYXIgaW4gdGFnIG5hbWVzLiAgQWxzbyBhZGQgJz0nIGFz
IGl0J3MKKwkJICAgcmVsYXRpb25hbCBpbiB0aGUgdmFzdCBtYWpvcml0eSBvZiBjYXNlcy4gICov
CiAJCWZvciAocCA9IGNwOwotCQkgICAgICghY19pc3NwYWNlICgqcCkgJiYgKnAgIT0gJyMnICYm
Ci0JCSAgICAgICpwICE9IFRFWF9vcGdycCAmJiAqcCAhPSBURVhfY2xncnApOworCQkgICAgICgh
Y19pc3NwYWNlICgqcCkgJiYgKnAgIT0gJyMnICYmICpwICE9ICc9JyAmJgorCQkgICAgICAqcCAh
PSAnWycgJiYgKnAgIT0gJygnICYmICpwICE9IFRFWF9vcGdycCAmJgorCQkgICAgICAqcCAhPSBU
RVhfY2xncnApOwogCQkgICAgIHArKykKLQkJICBjb250aW51ZTsKKwkJICAvKiBBbGxvdyBvbmx5
IG9uZSBlc2NhcGUgY2hhciBpbiBhIHRhZyBuYW1lLCB3aGljaAorCQkgICAgIChwcmltYXJpbHkp
IGVuYWJsZXMgdGFnZ2luZyBhIFRlWCBjb21tYW5kJ3MgZGlmZmVyZW50LAorCQkgICAgIHBvc3Np
Ymx5IHRlbXBvcmFyeSwgJ1xsZXQnIGJpbmRpbmdzLiAgKi8KKwkJICBpZiAoKnAgPT0gVEVYX2Vz
YykKKwkJICAgIHsKKwkJICAgICAgaWYgKCFvbmVfZXNjKQorCQkJeworCQkJICBvbmVfZXNjID0g
dHJ1ZTsKKwkJCSAgY29udGludWU7CisJCQl9CisJCSAgICAgIGVsc2UKKwkJCWJyZWFrOworCQkg
ICAgfQorCQkgIGVsc2UKKwkJICAgIGNvbnRpbnVlOworCQkvKiBSZS1zY2FuIHRvIGNhdGNoICho
aWdobHkgdW51c3VhbCkgY2FzZXMgd2hlcmUgYQorCQkgICBjb21tYW5kIG5hbWUgaXMgb2YgdGhl
IGZvcm0gJ1woJy4gICovCisJCWlmICgoKnAgPT0gJygnIHx8ICpwID09ICdbJykgJiYgKHAgLSBj
cCkgPCAyKQorCQkgIHsKKwkJICAgIGZvciAocCA9IGNwOworCQkJICghY19pc3NwYWNlICgqcCkg
JiYgKnAgIT0gJyMnICYmCisJCQkgICpwICE9IFRFWF9vcGdycCAmJiAqcCAhPSBURVhfY2xncnAp
OworCQkJIHArKykKKwkJICAgICAgY29udGludWU7CisJCSAgfQogCQluYW1lbGVuID0gcCAtIGNw
OwogCQlsaW5lbGVuID0gbGIubGVuOwogCQlpZiAoIW9wZ3JwIHx8ICpwID09IFRFWF9jbGdycCkK
ZGlmZiAtLWdpdCBhL2xpc3AvdGV4dG1vZGVzL3RleC1tb2RlLmVsIGIvbGlzcC90ZXh0bW9kZXMv
dGV4LW1vZGUuZWwKaW5kZXggYWI5NDAzNmQwMS4uM2E3MTc4YzA1NSAxMDA2NDQKLS0tIGEvbGlz
cC90ZXh0bW9kZXMvdGV4LW1vZGUuZWwKKysrIGIvbGlzcC90ZXh0bW9kZXMvdGV4LW1vZGUuZWwK
QEAgLTEyOTEsNiArMTI5MSw5IEBAIHRleC1jb21tb24taW5pdGlhbGl6YXRpb24KIAkgICAgICAo
c3ludGF4LXByb3BlcnRpemUtcnVsZXMgbGF0ZXgtc3ludGF4LXByb3BlcnRpemUtcnVsZXMpKQog
ICA7OyBUQUJzIGluIHZlcmJhdGltIGVudmlyb25tZW50cyBkb24ndCBkbyB3aGF0IHlvdSB0aGlu
ay4KICAgKHNldHEtbG9jYWwgaW5kZW50LXRhYnMtbW9kZSBuaWwpCisgIDs7IFNldCB1cCB4cmVm
IGJhY2tlbmQgaW4gVGVYIGJ1ZmZlcnMuCisgIChhZGQtaG9vayAneHJlZi1iYWNrZW5kLWZ1bmN0
aW9ucyAjJ3RleC0teHJlZi1iYWNrZW5kIG5pbCB0KQorICAodGV4LXNldC10aGluZ2F0cHQtc3lt
Ym9sKQogICA7OyBPdGhlciB2YXJzIHRoYXQgc2hvdWxkIGJlIGJ1ZmZlci1sb2NhbC4KICAgKG1h
a2UtbG9jYWwtdmFyaWFibGUgJ3RleC1jb21tYW5kKQogICAobWFrZS1sb2NhbC12YXJpYWJsZSAn
dGV4LXN0YXJ0LW9mLWhlYWRlcikKQEAgLTM2NTksNiArMzY2MiwzMzQgQEAgdGV4LWNoa3RleAog
ICAgICAgKHByb2Nlc3Mtc2VuZC1yZWdpb24gdGV4LWNoa3RleC0tcHJvY2VzcyAocG9pbnQtbWlu
KSAocG9pbnQtbWF4KSkKICAgICAgIChwcm9jZXNzLXNlbmQtZW9mIHRleC1jaGt0ZXgtLXByb2Nl
c3MpKSkpCiAKKwwKKzs7OyBYcmVmIGJhY2tlbmQKKworOzsgSGVyZSB3ZSBkZWZpbmUgYW4geHJl
ZiBiYWNrZW5kIGZvciBUZVgsIGFkYXB0aW5nIHRoZSBkZWZhdWx0IGV0YWdzCis7OyBiYWNrZW5k
IHNvIHRoYXQgdGhlIG1haW4geHJlZiB1c2VyIGNvbW1hbmRzIChpbmNsdWRpbmcKKzs7IGB4cmVm
LWZpbmQtZGVmaW5pdGlvbnMnLCBgeHJlZi1maW5kLWFwcm9wb3MnLCBhbmQKKzs7IGB4cmVmLWZp
bmQtcmVmZXJlbmNlcycgW29uIE0tLiwgQy1NLS4sIGFuZCBNLT8sIHJlc3BlY3RpdmVseV0pIHdv
cmsKKzs7IGluIFRlWCBidWZmZXJzLiAgVGhpcyBtb3N0bHkgaW52b2x2ZXMgZGVmaW5pbmcgYSBu
ZXcgVEhJTkcgZm9yCis7OyBgdGhpbmctYXQtcG9pbnQnICh0ZXhzeW1ib2wpLCB0aGVuIHN1YnN0
aXR1dGluZyB0aGF0IFRISU5HIGZvcgorOzsgYHN5bWJvbCcgaW4gVGVYIGJ1ZmZlcnMsIGF0IGxl
YXN0IGJ5IChjb25maWd1cmFibGUpIGRlZmF1bHQuICBUaGUKKzs7IFRlWCBlc2NhcGUgY2hhcmFj
dGVyIHdpbGwgYnkgZGVmYXVsdCBhcHBlYXIgaW4gdGhlIHJlc3VsdGluZyBzdHJpbmcKKzs7IG9u
bHkgd2hlbiB0aGUgeHJlZiBjb21tYW5kIHVzZXMgc3RyaW5nIHNlYXJjaCBhbmQgbm90IHJlZ2V4
cAorOzsgc2VhcmNoLCB0aG91Z2ggdGhpcyB0b28gaXMgY29uZmlndXJhYmxlLiAgVGhlIG5ldyBU
SElORyB0eXBlIGFsc28KKzs7IGltcHJvdmVzIHRoZSBhY2N1cmFjeSBvZiBvdGhlciBjb21tYW5k
cyB0aGF0IHVzZSBgdGhpbmctYXQtcG9pbnQnCis7OyBpbiBUZVggYnVmZmVycywgbGlrZSBgcHJv
amVjdC1maW5kLXJlZ2V4cCcuICBUT0RPOiBJbmNsdWRlIGNvbW1hbmRzCis7OyB0aGF0IGNhbGwg
YGJvdW5kcy1vZi10aGluZy1hdC1wb2ludCcgKGZvciBleGFtcGxlCis7OyBgaXNlYXJjaC1mb3J3
YXJkLXRoaW5nLWF0LXBvaW50JykgaW4gdGhlIG1lY2hhbmlzbS4KKworKGRlZnZhciB0ZXgtdGhp
bmdhdHB0LW1vZGVzLWxpc3QKKyAgJyh0ZXgtbW9kZSBkb2N0ZXgtbW9kZSBsYXRleC1tb2RlIHBs
YWluLXRleC1tb2RlIHNsaXRleC1tb2RlKQorICAiTWFqb3IgbW9kZXMgd2hlcmUgYHRoaW5nLWF0
LXBvaW50JyBtYXkgdXNlIHRoZSBgdGV4c3ltYm9sJyB0eXBlLgorCitXaGVuIGEgYnVmZmVyJ3Mg
YG1ham9yLW1vZGUnIGlzIGluIHRoaXMgbGlzdCwgYW5kIHdoZW4KK2B0ZXgtdGhpbmdhdHB0LWlz
LXRleHN5bWJvbCcgaXMgdCAodGhlIGRlZmF1bHQpLCBhbnkgY29tbWFuZCBpbgordGhhdCBidWZm
ZXIgdGhhdCBjYWxscyBgdGhpbmctYXQtcG9pbnQnIHdpdGggYSBgc3ltYm9sJyBhcmd1bWVudAor
YWN0dWFsbHkgdXNlcyB0aGUgYHRleHN5bWJvbCcgYXJndW1lbnQsIGluc3RlYWQuIikKKworKGRl
ZmN1c3RvbSB0ZXgtdGhpbmdhdHB0LWlzLXRleHN5bWJvbCB0CisgICJXaGVuIG5vbi1uaWwgcmVw
bGFjZSBgc3ltYm9sJyBieSBgdGV4c3ltYm9sJyBmb3IgYHRoaW5nLWF0LXBvaW50Jy4KKworVGhp
cyBhcHBsaWVzIG9ubHkgdG8gVGVYIGJ1ZmZlcnMuICBUaGUgYHRleHN5bWJvbCcgXCJ0aGluZ1wi
Cittb2RpZmllcyB0aGUgc3RhbmRhcmQgYHN5bWJvbCcgZm9yIHVzZSBpbiBzdWNoIGJ1ZmZlcnMu
CisKK1doZW4gbmlsLCByZXN0b3JlIHRoZSBkZWZhdWx0IGJlaGF2aW9yIG9mIGB0aGluZy1hdC1w
b2ludCcgaW4gVGVYCitidWZmZXJzLgorCitDdXN0b20gd2lsbCBhdXRvbWF0aWNhbGx5IGFwcGx5
IGNoYW5nZXMgaW4gYWxsIFRlWCBidWZmZXJzLCBidXQKK2lmIHlvdSBzZXQgdGhlIHZhcmlhYmxl
IG91dHNpZGUgb2YgQ3VzdG9tIGl0IHdvbid0IHRha2UgZWZmZWN0Cit1bnRpbCB5b3UgYXBwbHkg
aXQgd2l0aCBcXFt0ZXgtc2V0LXRoaW5nYXRwdC1zeW1ib2xdLiAgV2l0aG91dCBhCitwcmVmaXgg
YXJndW1lbnQgKFxcW3VuaXZlcnNhbC1hcmd1bWVudF0pIHRoaXMgYXBwbGllcyBvbmx5IHRvIHRo
ZQorY3VycmVudCBidWZmZXIsIGJ1dCB3aXRoIG9uZSBpdCBhcHBsaWVzIHRvIGFsbCBUZVggYnVm
ZmVycyBpbgorYGJ1ZmZlci1saXN0Jy4gIChUZVggYnVmZmVycyBhcmUgdGhvc2Ugd2hvc2UgYG1h
am9yLW1vZGUnIGlzIGEKK21lbWJlciBvZiBgdGV4LXRoaW5nYXRwdC1tb2Rlcy1saXN0Jy4pIgor
ICA6dHlwZSAnYm9vbGVhbgorICA6Z3JvdXAgJ3RleC1maWxlCisgIDppbml0aWFsaXplICMnY3Vz
dG9tLWluaXRpYWxpemUtZGVmYXVsdAorICA6c2V0IChsYW1iZGEgKHZhciB2YWwpCisgICAgICAg
ICAoc2V0LWRlZmF1bHQgdmFyIHZhbCkKKyAgICAgICAgICh0ZXgtc2V0LXRoaW5nYXRwdC1zeW1i
b2wgdCkpCisgIDp2ZXJzaW9uICIyOS4xIikKKworKGRlZmN1c3RvbSB0ZXgtdGhpbmdhdHB0LWlu
Y2x1ZGUtZXNjYXBlICcoeHJlZi1maW5kLWRlZmluaXRpb25zCisgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB4cmVmLWZpbmQtZGVmaW5pdGlvbnMtb3RoZXItd2luZG93
CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB4cmVmLWZpbmQtZGVm
aW5pdGlvbnMtb3RoZXItZnJhbWUpCisgICJJZiBub24tbmlsLCBpbmNsdWRlIGB0ZXgtZXNjYXBl
LWNoYXInIGluIGB0aGluZy1hdC1wb2ludCcuCisKK1RoaXMgdmFyaWFibGUgb25seSB0YWtlcyBl
ZmZlY3Qgd2hlbiBgdGV4LXRoaW5nYXRwdC1pcy10ZXhzeW1ib2wnCitpcyB0ICh0aGUgZGVmYXVs
dCksIGNoYW5naW5nIHRoZSBhcmd1bWVudCBwYXNzZWQgdG8KK2B0aGluZy1hdC1wb2ludCcgZnJv
bSBgc3ltYm9sJyB0byBgdGV4c3ltYm9sJy4gIFdoZW4gdGhhdCBpcyB0aGUKK2Nhc2UsIHRoZSB2
YWx1ZXMgb2YgdGhpcyB2YXJpYWJsZSBhY3QgYXMgZm9sbG93czoKKworV2hlbiB0LCBgdGhpbmct
YXQtcG9pbnQnIHdpbGwgYWx3YXlzIGluY2x1ZGUgYQorYHRleC1lc2NhcGUtY2hhcicgKHVzdWFs
bHkgYFxcJyksIHNob3VsZCBvbmUgYmUgcHJlc2VudCwgaW4gdGhlCitzdHJpbmcgaXQgcmV0dXJu
cyBpbiBUZVggYnVmZmVycy4KKworV2hlbiBuaWwsIGB0aGluZy1hdC1wb2ludCcgd2lsbCBuZXZl
ciBpbmNsdWRlIHRoZQorYHRleC1lc2NhcGUtY2hhcicgaW4gdGhlIHN0cmluZyBpdCByZXR1cm5z
IGluIFRlWCBidWZmZXJzLgorCitPdGhlcndpc2UsIGl0J3MgYSBsaXN0IG9mIGNvbW1hbmRzIGZv
ciB3aGljaCBgdGhpbmctYXQtcG9pbnQnCit3aWxsIGFsd2F5cyBpbmNsdWRlIHRoZSBgdGV4LWVz
Y2FwZS1jaGFyJyBpbiB0aGUgc3RyaW5nIGl0CityZXR1cm5zLiAgVGhlIHRocmVlIHhyZWYgY29t
bWFuZHMgbGlzdGVkIGJ5IGRlZmF1bHQgbWF5IGNlYXNlIHRvCitmdW5jdGlvbiBwcm9wZXJseSBp
biBUZVggYnVmZmVycyBpZiBzZXQgdG8gbmlsLCBidXQgc2V0dGluZworYHRleC14cmVmLXRyeS1h
bHRlcm5hdGUtZm9ybXMnIHRvIHQgd2lsbCByZWN0aWZ5IHRoYXQuIgorICA6dHlwZSAnKGNob2lj
ZSAoY29uc3QgOnRhZyAiQWx3YXlzIGluY2x1ZGUgdGV4LWVzY2FwZS1jaGFyIiB0KQorICAgICAg
ICAgICAgICAgICAoY29uc3QgOnRhZyAiTmV2ZXIgaW5jbHVkZSB0ZXgtZXNjYXBlLWNoYXIiIG5p
bCkKKyAgICAgICAgICAgICAgICAgKHNldCA6dGFnICJJbmNsdWRlIHRleC1lc2NhcGUtY2hhciBm
b3IgdGhlc2UgY29tbWFuZHMiCisJCSAgICAgIChyZXBlYXQgOmlubGluZSB0IChzeW1ib2wgOnRh
ZyAiY29tbWFuZCIpKSkpCisgIDpncm91cCAndGV4LWZpbGUKKyAgOnZlcnNpb24gIjI5LjEiKQor
CisoZGVmY3VzdG9tIHRleC14cmVmLXRyeS1hbHRlcm5hdGUtZm9ybXMgbmlsCisgICJOb24tbmls
IG1lYW5zIGZpbmQgZGVmaW5pdGlvbnMgb2YgYWx0ZXJuYXRlIGZvcm1zIG9mIGNvbW1hbmRzLgor
CitJZiBgeHJlZi1maW5kLWRlZmluaXRpb25zJyByZXR1cm5zIG5pbCBmb3IgdGhlIGN1cnJlbnQg
Zm9ybSBvZgordGhlIFRlWCBjb21tYW5kIG5hbWUsIHRyeSB0aGUgYWx0ZXJuYXRpdmUgZm9ybSwg
d2hpY2ggd2lsbCBoYXZlCit0aGUgYHRleC1lc2NhcGUtY2hhcicgKHVzdWFsbHkgYFxcJykgZWl0
aGVyIHN0cmlwcGVkIGZyb20gb3IKK3ByZXBlbmRlZCB0byB0aGUgY3VycmVudCBmb3JtLCBkZXBl
bmRpbmcgb24gd2hldGhlciBvciBub3QgdGhlCitjdXJyZW50IGZvcm0gc3RhcnRzIHdpdGggdGhh
dCBjaGFyYWN0ZXIuCisKK1RoaXMgbWF5IGJlIHBhcnRpY3VsYXJseSB1c2VmdWwgaW4gZG9jdW1l
bnRzIHRoYXQgbWl4IGBcXGRlZicgYW5kCitgXFxjc2RlZicgd2hlbiBkZWZpbmluZyBjb21tYW5k
cy4iCisgIDp0eXBlICdib29sZWFuCisgIDpncm91cCAndGV4LWZpbGUKKyAgOnZlcnNpb24gIjI5
LjEiKQorCisoZGVmdmFyIHRleC1lc2NhcGUtY2hhciA/XFwKKyAgIlRoZSBjdXJyZW50IFRlWCBl
c2NhcGUgY2hhcmFjdGVyLgorCitUaGUgYGV0YWdzJyBwcm9ncmFtIG9ubHkgcmVjb2duaXplcyBg
XFwnICg5MikgYW5kIGAhJyAoMzMpIGFzCitlc2NhcGUgY2hhcmFjdGVycyBpbiBUZVggZG9jdW1l
bnRzLCBhbmQgaWYgaXQgZGV0ZWN0cyB0aGUgbGF0dGVyCitpdCBhbHNvIHVzZXMgYDw+JyBhcyB0
aGUgVGVYIGdyb3VwaW5nIGNvbnN0cnVjdCByYXRoZXIgdGhhbiBge30nLgorU2V0dGluZyB0aGlz
IHZhcmlhYmxlIHRvIGFueXRoaW5nIG90aGVyIHRoYW4gYFxcJyBvciBgIScgd2lsbCBub3QKK2Jl
IHVzZWZ1bCB3aXRob3V0IGNoYW5nZXMgdG8gYGV0YWdzJywgYXQgbGVhc3QgZm9yIGNvbW1hbmRz
IHRoYXQKK3NlYXJjaCB0YWdzIHRhYmxlcywgc3VjaCBhcyBcXFt4cmVmLWZpbmQtZGVmaW5pdGlv
bnNdIGFuZCBcCitcXFt4cmVmLWZpbmQtYXByb3Bvc10uIikKKworKGRlZnZhciB0ZXgtdGhpbmdh
dHB0LXN5bnRheC10YWJsZQorICAobGV0KiAoKG9zdCAoaWYgKGJvdW5kcCAnVGVYLW1vZGUtc3lu
dGF4LXRhYmxlKQorICAgICAgICAgICAgICAgICAgVGVYLW1vZGUtc3ludGF4LXRhYmxlCisgICAg
ICAgICAgICAgICAgdGV4LW1vZGUtc3ludGF4LXRhYmxlKSkKKyAgICAgICAgIChzdCAobWFrZS1z
eW50YXgtdGFibGUgb3N0KSkpCisgICAgKG1vZGlmeS1zeW50YXgtZW50cnkgPyMgIiciIHN0KQor
ICAgIChtb2RpZnktc3ludGF4LWVudHJ5ID89ICInIiBzdCkKKyAgICAobW9kaWZ5LXN5bnRheC1l
bnRyeSA/YCAiJyIgc3QpCisgICAgKG1vZGlmeS1zeW50YXgtZW50cnkgP1wiICInIiBzdCkKKyAg
ICAobW9kaWZ5LXN5bnRheC1lbnRyeSA/JyAiJyIgc3QpCisgICAgc3QpCisgICJTeW50YXggdGFi
bGUgZm9yIGRlbGltaXRpbmcgYHRoaW5nLWF0LXBvaW50JyBpbiBUZVggYnVmZmVycy4KKworV2hl
biBgdGV4LXRoaW5nYXRwdC1pcy10ZXhzeW1ib2wnIGlzIHQsIHRoaXMgc3ludGF4IHRhYmxlIGhl
bHBzCit0byBkZWZpbmUgd2hhdCBhIGB0ZXhzeW1ib2wnIGlzLiIpCisKKyhkZWZ1biB0ZXgtLXhy
ZWYtYmFja2VuZCAoKSAndGV4KQorCis7OyBTZXR1cCBBVUNUZVggbW9kZXMuICAoU2hvdWxkIHRo
aXMgYmUgaW4gQVVDVGVYIGl0c2VsZj8pCisKKyhhZGQtaG9vayAnVGVYLW1vZGUtaG9vayAjJ3Rl
eC1zZXQtYXVjdGV4LXhyZWYtYmFja2VuZCkKKyhhZGQtaG9vayAnVGVYLW1vZGUtaG9vayAjJ3Rl
eC1zZXQtdGhpbmdhdHB0LXN5bWJvbCkKKworKGRlZnVuIHRleC1zZXQtYXVjdGV4LXhyZWYtYmFj
a2VuZCAoKQorICAoYWRkLWhvb2sgJ3hyZWYtYmFja2VuZC1mdW5jdGlvbnMgIyd0ZXgtLXhyZWYt
YmFja2VuZCBuaWwgdCkpCisKKyhkZWNsYXJlLWZ1bmN0aW9uIHhyZWYtaXRlbS1sb2NhdGlvbiAi
eHJlZiIpCisoZGVjbGFyZS1mdW5jdGlvbiB4cmVmLS1wcm9qZWN0LXJvb3QgInhyZWYiIChwcm9q
ZWN0KSkKKyhkZWNsYXJlLWZ1bmN0aW9uIHhyZWYtLWNvbnZlcnQtaGl0cyAieHJlZiIgKGhpdHMg
cmVnZXhwKSkKKyhkZWNsYXJlLWZ1bmN0aW9uIGFwcm9wb3MtcGFyc2UtcGF0dGVybiAiYXByb3Bv
cyIgKHBhdHRlcm4pKQorKGRlY2xhcmUtZnVuY3Rpb24gc2VtYW50aWMtc3ltcmVmLXBlcmZvcm0t
c2VhcmNoICJzZW1hbnRpYy9zeW1yZWYiKQorKGRlY2xhcmUtZnVuY3Rpb24gc2VtYW50aWMtc3lt
cmVmLWluc3RhbnRpYXRlICJzZW1hbnRpYy9zeW1yZWYiKQorKGRlY2xhcmUtZnVuY3Rpb24gcHJv
amVjdC1leHRlcm5hbC1yb290cyAicHJvamVjdCIpCisoZGVjbGFyZS1mdW5jdGlvbiBmaW5kLXRh
Zy0tY29tcGxldGlvbi1pZ25vcmUtY2FzZSAiZXRhZ3MiKQorKGRlY2xhcmUtZnVuY3Rpb24gZXRh
Z3MtLXhyZWYtZmluZC1kZWZpbml0aW9ucyAiZXRhZ3MiKQorKGRlY2xhcmUtZnVuY3Rpb24gZXRh
Z3MtLXhyZWYtYXByb3Bvcy1hZGRpdGlvbmFsICJldGFncyIgKHJlZ2V4cCkpCisoZGVjbGFyZS1m
dW5jdGlvbiBjbC1kZWxldGUtaWYgImNsLXNlcSIpCisoZGVmdmFyIGV0YWdzLXhyZWYtcHJlZmVy
LWN1cnJlbnQtZmlsZSkKKworKGNsLWRlZm1ldGhvZCB4cmVmLWJhY2tlbmQtaWRlbnRpZmllci1h
dC1wb2ludCAoKF9iYWNrZW5kIChlcWwgJ3RleCkpKQorICAocmVxdWlyZSAnZXRhZ3MpCisgICh0
aGluZy1hdC1wb2ludCAnc3ltYm9sIHQpKQorCisoY2wtZGVmbWV0aG9kIHhyZWYtYmFja2VuZC1p
ZGVudGlmaWVyLWNvbXBsZXRpb24tdGFibGUgKChfYmFja2VuZAorICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGVxbCAndGV4KSkpCisgICh0
YWdzLWxhenktY29tcGxldGlvbi10YWJsZSkpCisKKyhjbC1kZWZtZXRob2QgeHJlZi1iYWNrZW5k
LWlkZW50aWZpZXItY29tcGxldGlvbi1pZ25vcmUtY2FzZSAoKF9iYWNrZW5kCisgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoZXFs
ICd0ZXgpKSkKKyAgKGZpbmQtdGFnLS1jb21wbGV0aW9uLWlnbm9yZS1jYXNlKSkKKworKGNsLWRl
Zm1ldGhvZCB4cmVmLWJhY2tlbmQtZGVmaW5pdGlvbnMgKChfYmFja2VuZCAoZXFsICd0ZXgpKSBz
eW1ib2wpCisgIChsZXQqICgoZmlsZSAoYW5kIGJ1ZmZlci1maWxlLW5hbWUgKGV4cGFuZC1maWxl
LW5hbWUgYnVmZmVyLWZpbGUtbmFtZSkpKQorICAgICAgICAgKGFsdC1zeW0gKGlmIChjaGFyLWVx
dWFsIHRleC1lc2NhcGUtY2hhciAoYXJlZiBzeW1ib2wgMCkpCisgICAgICAgICAgICAgICAgICAg
ICAgKHN1YnN0cmluZyBzeW1ib2wgMSkKKyAgICAgICAgICAgICAgICAgICAgKGNvbmNhdCAoc3Ry
aW5nIHRleC1lc2NhcGUtY2hhcikgc3ltYm9sKSkpCisgICAgICAgICAocHJlbGltLWRlZmluaXRp
b25zIChldGFncy0teHJlZi1maW5kLWRlZmluaXRpb25zIHN5bWJvbCkpCisgICAgICAgICAoZGVm
aW5pdGlvbnMgKGlmIChvciBwcmVsaW0tZGVmaW5pdGlvbnMKKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIChub3QgdGV4LXhyZWYtdHJ5LWFsdGVybmF0ZS1mb3JtcykpCisgICAgICAgICAg
ICAgICAgICAgICAgICAgIHByZWxpbS1kZWZpbml0aW9ucworICAgICAgICAgICAgICAgICAgICAg
ICAgKGV0YWdzLS14cmVmLWZpbmQtZGVmaW5pdGlvbnMgYWx0LXN5bSkpKQorICAgICAgICAgc2Ft
ZS1maWxlLWRlZmluaXRpb25zKQorICAgICh3aGVuIChhbmQgZXRhZ3MteHJlZi1wcmVmZXItY3Vy
cmVudC1maWxlIGZpbGUpCisgICAgICAoc2V0cSBkZWZpbml0aW9ucworICAgICAgICAgICAgKGNs
LWRlbGV0ZS1pZgorICAgICAgICAgICAgIChsYW1iZGEgKGRlZmluaXRpb24pCisgICAgICAgICAg
ICAgICAod2hlbiAoZXF1YWwgZmlsZQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICh4cmVm
LWxvY2F0aW9uLWdyb3VwCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICh4cmVmLWl0ZW0t
bG9jYXRpb24gZGVmaW5pdGlvbikpKQorICAgICAgICAgICAgICAgICAocHVzaCBkZWZpbml0aW9u
IHNhbWUtZmlsZS1kZWZpbml0aW9ucykKKyAgICAgICAgICAgICAgICAgdCkpCisgICAgICAgICAg
ICAgZGVmaW5pdGlvbnMpKQorICAgICAgKHNldHEgZGVmaW5pdGlvbnMgKG5jb25jIChucmV2ZXJz
ZSBzYW1lLWZpbGUtZGVmaW5pdGlvbnMpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ZGVmaW5pdGlvbnMpKSkKKyAgICBkZWZpbml0aW9ucykpCisKKyhjbC1kZWZtZXRob2QgeHJlZi1i
YWNrZW5kLWFwcm9wb3MgKChfYmFja2VuZCAoZXFsICd0ZXgpKSBwYXR0ZXJuKQorICAobGV0ICgo
cmVnZXhwICh0ZXgteHJlZi1hcHJvcG9zLXJlZ2V4cCBwYXR0ZXJuKSkpCisgICAgKG5jb25jCisg
ICAgIChvcgorICAgICAgKGV0YWdzLS14cmVmLWZpbmQtZGVmaW5pdGlvbnMgcmVnZXhwIHQpCisg
ICAgICAoZXRhZ3MtLXhyZWYtZmluZC1kZWZpbml0aW9ucyBwYXR0ZXJuIHQpKQorICAgICAoZXRh
Z3MtLXhyZWYtYXByb3Bvcy1hZGRpdGlvbmFsIHJlZ2V4cCkpKSkKKworKGNsLWRlZm1ldGhvZCB4
cmVmLWJhY2tlbmQtcmVmZXJlbmNlcyAoKF9iYWNrZW5kIChlcWwgJ3RleCkpIGlkZW50aWZpZXIp
CisgIChtYXBjYW4KKyAgIChsYW1iZGEgKGRpcikKKyAgICAgKG1lc3NhZ2UgIlNlYXJjaGluZyAl
cy4uLiIgZGlyKQorICAgICAocmVkaXNwbGF5KQorICAgICAocHJvZzEKKyAgICAgICAgICh0ZXgt
eHJlZi1yZWZlcmVuY2VzLWluLWRpcmVjdG9yeSBpZGVudGlmaWVyIGRpcikKKyAgICAgICAobWVz
c2FnZSAiU2VhcmNoaW5nICVzLi4uIGRvbmUiIGRpcikpKQorICAgKGxldCAoKHByIChwcm9qZWN0
LWN1cnJlbnQgdCkpKQorICAgICAoY29ucworICAgICAgKHhyZWYtLXByb2plY3Qtcm9vdCBwcikK
KyAgICAgIChwcm9qZWN0LWV4dGVybmFsLXJvb3RzIHByKSkpKSkKKworKGRlZnVuIHRleC14cmVm
LWFwcm9wb3MtcmVnZXhwIChwYXR0ZXJuKQorICAiUmV0dXJuIGEgcmVnZXhwIGZyb20gUEFUVEVS
TiBzaW1pbGFyIHRvIGBhcHJvcG9zJy4KKworVW5saWtlIHRoZSBzdGFuZGFyZCB4cmVmIGZ1bmN0
aW9uLCBpZiBgcmVnZXhwLXF1b3RlJyByZXR1cm5zIGEKK3N0cmluZyBkaWZmZXJlbnQgZnJvbSB0
aGUgb3JpZ2luYWwgUEFUVEVSTiwgdGhlIFRlWCBmdW5jdGlvbgorcGFzc2VzIHRoYXQgbW9kaWZp
ZWQgc3RyaW5nLCByYXRoZXIgdGhhbiBQQVRURVJOIGl0c2VsZiwgdG8KK2BhcHJvcG9zLXBhcnNl
LXBhdHRlcm4nLiIKKyAgKGxldCAoKHJlIChyZWdleHAtcXVvdGUgcGF0dGVybikpKQorICAgIChh
cHJvcG9zLXBhcnNlLXBhdHRlcm4KKyAgICAgKGlmIChzdHJpbmctZXF1YWwgcmUgcGF0dGVybikK
KyAgICAgICAgIDs7IFNwbGl0IGludG8gd29yZHMKKyAgICAgICAgIChvciAoc3BsaXQtc3RyaW5n
IHBhdHRlcm4gIlsgXHRdKyIgdCkKKyAgICAgICAgICAgICAodXNlci1lcnJvciAiTm8gd29yZCBs
aXN0IGdpdmVuIikpCisgICAgICAgcmUpKSkpCisKKyhkZWZ1biB0ZXgteHJlZi1yZWZlcmVuY2Vz
LWluLWRpcmVjdG9yeSAoc3ltYm9sIGRpcikKKyAgIkZpbmQgYWxsIHJlZmVyZW5jZXMgdG8gU1lN
Qk9MIGluIGRpcmVjdG9yeSBESVIuCitSZXR1cm4gYSBsaXN0IG9mIHhyZWYgdmFsdWVzLgorCitU
aGlzIGZ1bmN0aW9uIHVzZXMgdGhlIFNlbWFudGljIFN5bWJvbCBSZWZlcmVuY2UgQVBJLiAgSW4g
VGVYCitidWZmZXJzIHRoZSB2YWx1ZSByZXR1cm5lZCB3aGVuIHBhc3NpbmcgU1lNQk9MIHRvIGBy
ZWdleHAtcXVvdGUnCitiZWNvbWVzIHRoZSBkZWZhdWx0IHNlYXJjaCB0ZXJtLiAgSWYgdGhpcyBz
eW1yZWYgaW5zdGFudGlhdGlvbgorZmluZHMgbm8gbWF0Y2hlcywgYSBzZWNvbmQgdHJpZXMgYWdh
aW4gd2l0aCB0aGUgb3JpZ2luYWwgU1lNQk9MCithcyBzZWFyY2ggdGVybSwgaW5zdGVhZC4gIEJv
dGggc2VhcmNoZXMgc2V0IGtleXdvcmQgYHNlYXJjaHR5cGU6JwordG8gXFw9J3JlZ2V4cCBpbnN0
ZWFkIG9mIHhyZWYncyBcXD0nc3ltYm9sLgorCitTZWUgYHNlbWFudGljLXN5bXJlZi10b29sLWFs
aXN0JyBmb3IgZGV0YWlscyBvbiB3aGljaCB0b29scyBhcmUKK3VzZWQsIGFuZCB3aGVuLiAgU2Vl
IGFsc28gYHhyZWYtcmVmZXJlbmNlcy1pbi1kaXJlY3RvcnknIGFuZAorY29tbWVudHMgaW4gaXRz
IGNvZGUsIHRoZSBsYXR0ZXIgY29waWVkIGludG8gdGhlIFRlWAoraW1wbGVtZW50YXRpb24gZm9y
IGNvbnZlbmllbmNlLiIKKyAgKGNsLWFzc2VydCAoZGlyZWN0b3J5LW5hbWUtcCBkaXIpKQorICAo
cmVxdWlyZSAnc2VtYW50aWMvc3ltcmVmKQorICAoZGVmdmFyIHNlbWFudGljLXN5bXJlZi10b29s
KQorICAoZGVmdmFyIGVkZS1taW5vci1tb2RlKQorCisgIDs7IFNvbWUgc3ltcmVmIGJhY2tlbmRz
IHVzZSBgZWRlLXByb2plY3Qtcm9vdC1kaXJlY3RvcnknIGFzIHRoZSByb290CisgIDs7IGRpcmVj
dG9yeSBmb3IgdGhlIHNlYXJjaCwgcmF0aGVyIHRoYW4gYGRlZmF1bHQtZGlyZWN0b3J5Jy4gU2lu
Y2UKKyAgOzsgdGhlIGNhbGxlciBoYXMgc3BlY2lmaWVkIGBkaXInLCB3ZSBiaW5kIGBlZGUtbWlu
b3ItbW9kZScgdG8gbmlsCisgIDs7IHRvIGZvcmNlIHRoZSBiYWNrZW5kIHRvIHVzZSBgZGVmYXVs
dC1kaXJlY3RvcnknLgorICAobGV0KiAoKGVkZS1taW5vci1tb2RlIG5pbCkKKyAgICAgICAgIChk
ZWZhdWx0LWRpcmVjdG9yeSBkaXIpCisgICAgICAgICA7OyBGSVhNRTogUmVtb3ZlIENTY29wZSBh
bmQgR2xvYmFsIGZyb20gdGhlIHJlY29nbml6ZWQgdG9vbHM/CisgICAgICAgICA7OyBUaGUgY3Vy
cmVudCBpbXBsZW1lbnRhdGlvbnMgaW50ZXJwcmV0IHRoZSBzeW1ib2wgc2VhcmNoIGFzCisgICAg
ICAgICA7OyAiZmluZCBhbGwgY2FsbHMgdG8gdGhlIGdpdmVuIGZ1bmN0aW9uIiwgYnV0IG5vdCBm
dW5jdGlvbgorICAgICAgICAgOzsgZGVmaW5pdGlvbi4gQW5kIHRoZXkgcmV0dXJuIG5vdGhpbmcg
d2hlbiBwYXNzZWQgYSB2YXJpYWJsZQorICAgICAgICAgOzsgbmFtZSwgZXZlbiBhIGdsb2JhbCBv
bmUuCisgICAgICAgICAoc2VtYW50aWMtc3ltcmVmLXRvb2wgJ2RldGVjdCkKKyAgICAgICAgIChj
YXNlLWZvbGQtc2VhcmNoIG5pbCkKKyAgICAgICAgICh0ZXhzeW1ib2wgKHJlZ2V4cC1xdW90ZSBz
eW1ib2wpKQorICAgICAgICAgKGluc3QgKHNlbWFudGljLXN5bXJlZi1pbnN0YW50aWF0ZSA6c2Vh
cmNoZm9yIHRleHN5bWJvbAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICA6c2VhcmNodHlwZSAncmVnZXhwCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDpzZWFyY2hzY29wZSAnc3ViZGlycworICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICA6cmVzdWx0dHlwZSAnbGluZS1hbmQtdGV4dCkpCisgICAg
ICAgICAoYWx0LWluc3QgKHNlbWFudGljLXN5bXJlZi1pbnN0YW50aWF0ZSA6c2VhcmNoZm9yIHN5
bWJvbAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOnNl
YXJjaHR5cGUgJ3JlZ2V4cAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgOnNlYXJjaHNjb3BlICdzdWJkaXJzCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICA6cmVzdWx0dHlwZSAnbGluZS1hbmQtdGV4dCkpKQorICAg
IChvcgorICAgICAoeHJlZi0tY29udmVydC1oaXRzIChzZW1hbnRpYy1zeW1yZWYtcGVyZm9ybS1z
ZWFyY2ggaW5zdCkKKyAgICAgICAgICAgICAgICAgICAgICAgICAoZm9ybWF0ICIlcyIgdGV4c3lt
Ym9sKSkKKyAgICAgKHhyZWYtLWNvbnZlcnQtaGl0cyAoc2VtYW50aWMtc3ltcmVmLXBlcmZvcm0t
c2VhcmNoIGFsdC1pbnN0KQorICAgICAgICAgICAgICAgICAgICAgICAgIChmb3JtYXQgIiVzIiBz
eW1ib2wpKSkpKQorCisocHV0ICd0ZXhzeW1ib2wgJ2JlZ2lubmluZy1vcCAndGV4LXRoaW5nYXRw
dC0tYmVnaW5uaW5nLW9mLXRleHN5bWJvbCkKKworKHB1dCAndGV4c3ltYm9sICdlbmQtb3AgJ3Rl
eC10aGluZ2F0cHQtLWVuZC1vZi10ZXhzeW1ib2wpCisKKyhkZWZ1biB0ZXgtc2V0LXRoaW5nYXRw
dC1zeW1ib2wgKCZvcHRpb25hbCBhbGwpCisgICJTZXQgbWVhbmluZyBvZiBgdGhpbmctYXQtcG9p
bnQnIGBzeW1ib2wnIGluIChBTEw/KSBUZVggYnVmZmVycy4KKworV2hlbiBgdGV4LXRoaW5nYXRw
dC1pcy10ZXhzeW1ib2wnIGlzIHQsIHNldCBgdGhpbmctYXQtcG9pbnQnIHRvCit1c2UgdGhlIGB0
ZXhzeW1ib2wnIFwidGhpbmdcIiBpbnN0ZWFkIG9mIGBzeW1ib2wnLCBvdGhlcndpc2UKK21haW50
YWluIG9yIHJlc3RvcmUgdGhlIGRlZmF1bHQuICBXaXRob3V0IGFuIG9wdGlvbmFsIEFMTCBtYWtl
CitjaGFuZ2VzIG9ubHkgaW4gY3VycmVudCBidWZmZXIsIHdpdGggQUxMIG1ha2UgY2hhbmdlcyBp
biBhbGwgVGVYCitidWZmZXJzIGluIGBidWZmZXItbGlzdCcuIgorICAoaW50ZXJhY3RpdmUgIlAi
KQorICAocmVxdWlyZSAndGhpbmdhdHB0KQorICAoaWYgYWxsCisgICAgICAoZG9saXN0IChidWYg
KGJ1ZmZlci1saXN0KSkKKyAgICAgICAgKHdpdGgtY3VycmVudC1idWZmZXIgYnVmCisgICAgICAg
ICAgKHRleC0tc3ltYm9sLW9yLXRleHN5bWJvbCkpKQorICAgICh0ZXgtLXN5bWJvbC1vci10ZXhz
eW1ib2wpKSkKKworKGRlZnVuIHRleC0tc3ltYm9sLW9yLXRleHN5bWJvbCAoKQorICAod2hlbiAo
bWVtcSBtYWpvci1tb2RlIHRleC10aGluZ2F0cHQtbW9kZXMtbGlzdCkKKyAgICAoaWYgdGV4LXRo
aW5nYXRwdC1pcy10ZXhzeW1ib2wKKyAgICAgICAgKHNldHEtbG9jYWwgdGhpbmctYXQtcG9pbnQt
cHJvdmlkZXItYWxpc3QKKyAgICAgICAgICAgICAgICAgICAgKGFkZC10by1saXN0ICd0aGluZy1h
dC1wb2ludC1wcm92aWRlci1hbGlzdAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICcoc3lt
Ym9sIC4gdGV4LS10aGluZy1hdC1wb2ludCkpKQorICAgICAgKHNldHEtbG9jYWwgdGhpbmctYXQt
cG9pbnQtcHJvdmlkZXItYWxpc3QKKyAgICAgICAgICAgICAgICAgIChkZWxldGUgJyhzeW1ib2wg
LiB0ZXgtLXRoaW5nLWF0LXBvaW50KQorICAgICAgICAgICAgICAgICAgICAgICAgICB0aGluZy1h
dC1wb2ludC1wcm92aWRlci1hbGlzdCkpKSkpCisKKyhkZWZ1biB0ZXgtLXRoaW5nLWF0LXBvaW50
ICgpCisgICJQYXNzIGB0aGluZycgdHlwZSBgdGV4c3ltYm9sJyB0byBgYm91bmRzLW9mLXRoaW5n
LWF0LXBvaW50Jy4KKworV2hlbiBgdGV4LXRoaW5nYXRwdC1pcy10ZXhzeW1ib2wnIGlzIHQsIGNh
bGxzIGluIFRlWCBidWZmZXJzIHRvCitgdGhpbmctYXQtcG9pbnQnIHdpdGggYXJndW1lbnQgYHN5
bWJvbCcgd2lsbCB1c2UgdGhpcyBmdW5jdGlvbi4iCisgIChsZXQqICgoc3l0YWIgKG1ha2Utc3lu
dGF4LXRhYmxlIHRleC10aGluZ2F0cHQtc3ludGF4LXRhYmxlKSkKKyAgICAgICAgIChib3VuZHMg
KHdpdGgtc3ludGF4LXRhYmxlIHN5dGFiCisgICAgICAgICAgICAgICAgICAgKHVubGVzcyAoY2hh
ci1lcXVhbCB0ZXgtZXNjYXBlLWNoYXIgP1xcKQorICAgICAgICAgICAgICAgICAgICAgKG1vZGlm
eS1zeW50YXgtZW50cnkgP1xcICJfIikKKyAgICAgICAgICAgICAgICAgICAgIChtb2RpZnktc3lu
dGF4LWVudHJ5IHRleC1lc2NhcGUtY2hhciAiXFwiKQorICAgICAgICAgICAgICAgICAgICAgKG1v
ZGlmeS1zeW50YXgtZW50cnkgPzwgIig+IikKKyAgICAgICAgICAgICAgICAgICAgIChtb2RpZnkt
c3ludGF4LWVudHJ5ID8+ICIpPCIpKQorICAgICAgICAgICAgICAgICAgIChib3VuZHMtb2YtdGhp
bmctYXQtcG9pbnQgJ3RleHN5bWJvbCkpKSkKKyAgICAod2hlbiBib3VuZHMKKyAgICAgIChidWZm
ZXItc3Vic3RyaW5nLW5vLXByb3BlcnRpZXMgKGNhciBib3VuZHMpIChjZHIgYm91bmRzKSkpKSkK
KworKGRlZnVuIHRleC0taW5jbHVkZS1lc2NhcGUtcCAoY29tbWFuZCkKKyAgKG9yIChlcSB0ZXgt
dGhpbmdhdHB0LWluY2x1ZGUtZXNjYXBlIHQpCisgICAgICAobWVtcSBjb21tYW5kIHRleC10aGlu
Z2F0cHQtaW5jbHVkZS1lc2NhcGUpKSkKKworKGRlZnVuIHRleC10aGluZ2F0cHQtLWJlZ2lubmlu
Zy1vZi10ZXhzeW1ib2wgKCkKKyAgIk1vdmUgcG9pbnQgdG8gdGhlIGJlZ2lubmluZyBvZiB0aGUg
Y3VycmVudCBUZVggc3ltYm9sLiIKKyAgKGFuZCAocmUtc2VhcmNoLWJhY2t3YXJkICJcXChbXVso
KV1cXHxcXChcXHN3XFx8XFxzX1xcfFxccy5cXCkrXFwpIikKKyAgICAgICAoc2tpcC1zeW50YXgt
YmFja3dhcmQgIndfLiIpCisgICAgICAgKHdoZW4gKHRleC0taW5jbHVkZS1lc2NhcGUtcCB0aGlz
LWNvbW1hbmQpCisgICAgICAgICAoc2tpcC1zeW50YXgtYmFja3dhcmQgIlxcLyIpKSkpCisKKyhk
ZWZ1biB0ZXgtdGhpbmdhdHB0LS1lbmQtb2YtdGV4c3ltYm9sICgpCisgICJNb3ZlIHBvaW50IHRv
IHRoZSBlbmQgb2YgdGhlIGN1cnJlbnQgVGVYIHN5bWJvbC4iCisgIChhbmQgKHJlLXNlYXJjaC1m
b3J3YXJkICJcXChbXVsoKV1cXHxcXChcXHN3XFx8XFxzX1xcfFxccy5cXCkrXFwpIikKKyAgICAg
ICAoc2tpcC1zeW50YXgtZm9yd2FyZCAid18uIikpKQorCiAobWFrZS1vYnNvbGV0ZS12YXJpYWJs
ZSAndGV4LW1vZGUtbG9hZC1ob29rCiAgICAgICAgICAgICAgICAgICAgICAgICAidXNlIGB3aXRo
LWV2YWwtYWZ0ZXItbG9hZCcgaW5zdGVhZC4iICIyOC4xIikKIChydW4taG9va3MgJ3RleC1tb2Rl
LWxvYWQtaG9vaykKLS0gCjIuMTcuNgoK
--000000000000d28fd905d71e8534--




Acknowledgement sent to David Fussner <dfussner@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#53749; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Thu, 8 Sep 2022 13:45:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.