GNU logs - #43086, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#43086: [PATCH] Allow tags backend to not query for TAGS file
Resent-From: "Philip K." <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 28 Aug 2020 12:51:02 +0000
Resent-Message-ID: <handler.43086.B.159861905117290 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 43086 <at> debbugs.gnu.org
From: "Philip K." <philipk@HIDDEN>
Date: Fri, 28 Aug 2020 14:50:38 +0200
Message-ID: <87k0xjue75.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@HIDDEN;
 helo=mout02.posteo.de
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 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,
 RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
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 (--)

--=-=-=
Content-Type: text/plain


Hi,

the xref backend for etags can be annoying at times, especially in
combination with other backends. This patch should improve the
situation, by allowing the user to configure how and when the etags
backend is activated. The new user option etags-query-file would allow
the backend to never query a TAGS file, or conditionally, depending on
the existence of a TAGS file (in which case it can also be automatically
loaded).

I could imagine this might be extended to allow an auto-generate option,
but that feature seems out of scope of this patch, and probably would
require some interoperation with project.el.

-- 
	Philip K.


--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
 filename=0001-Allow-tags-backend-to-not-query-for-TAGS-file.patch

From 6b141be5123d4cf37d743a9a12818442333658ed Mon Sep 17 00:00:00 2001
From: Philip K <philipk@HIDDEN>
Date: Fri, 28 Aug 2020 14:20:56 +0200
Subject: [PATCH] Allow tags backend to not query for TAGS file

* lisp/progmodes/etags.el (etags-query-file): Add variable
(etags--xref-backend): Respect etags-query-file
---
 lisp/progmodes/etags.el | 33 ++++++++++++++++++++++++++++++++-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/lisp/progmodes/etags.el b/lisp/progmodes/etags.el
index 2c5c36504a..60b162f19e 100644
--- a/lisp/progmodes/etags.el
+++ b/lisp/progmodes/etags.el
@@ -2069,8 +2069,39 @@ etags-xref-find-definitions-tag-order
 If you want `xref-find-definitions' to find the tagged files by their
 file name, add `tag-partial-file-name-match-p' to the list value.")
 
+(defcustom etags-query-file t
+  "Specify how and when to query TAGS file.
+If t, always query if no tags file has been loaded.
+If `check', only query if a TAGS file exists.
+If `check-and-set', automatically set TAGS file if exists, and don't
+query otherwise.
+If `set-or-check', set TAGS file if exists, or query user if not.
+If nil, a new table can be loaded using `visit-tags-table'."
+  :type '(choice (const :tag "Always query" t)
+                 (const :tag "Never query" nil)
+                 (const :tag "Query if exists" check)
+                 (const :tag "Set if exists" check-and-set)
+                 (const :tag "Query if not exists" set-or-check))
+  :version "28.1")
+
 ;;;###autoload
-(defun etags--xref-backend () 'etags)
+(defun etags--xref-backend ()
+  (and (cond ((or (null etags-query-file)
+                  tags-table-computed-list))
+             ((eq etags-query-file 'check)
+              (locate-dominating-file default-directory "TAGS"))
+             ((eq etags-query-file 'check-and-set)
+              (let ((dir (locate-dominating-file default-directory "TAGS")))
+                (when dir
+                  (visit-tags-table dir)
+                  t)))
+             ((eq etags-query-file 'set-or-check)
+              (let ((dir (locate-dominating-file default-directory "TAGS")))
+                (when dir
+                  (visit-tags-table dir))
+                t))
+             (etags-query-file))
+       'etags))
 
 (cl-defmethod xref-backend-identifier-at-point ((_backend (eql etags)))
   (find-tag--default))
-- 
2.26.2


--=-=-=--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: "Philip K." <philipk@HIDDEN>
Subject: bug#43086: Acknowledgement ([PATCH] Allow tags backend to not
 query for TAGS file)
Message-ID: <handler.43086.B.159861905117290.ack <at> debbugs.gnu.org>
References: <87k0xjue75.fsf@HIDDEN>
X-Gnu-PR-Message: ack 43086
X-Gnu-PR-Package: emacs
X-Gnu-PR-Keywords: patch
Reply-To: 43086 <at> debbugs.gnu.org
Date: Fri, 28 Aug 2020 12:51:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 43086 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
43086: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D43086
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#43086: [PATCH] Allow tags backend to not query for TAGS file
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 05 Sep 2020 00:46:02 +0000
Resent-Message-ID: <handler.43086.B43086.159926672725244 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: "Philip K." <philipk@HIDDEN>, 43086 <at> debbugs.gnu.org
References: <87k0xjue75.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <cfd9096b-6787-236e-7780-df2aa63a94d3@HIDDEN>
Date: Sat, 5 Sep 2020 03:45:17 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <87k0xjue75.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
 
 Content preview:  Hi! On 28.08.2020 15:50, Philip K. wrote: > the xref backend
    for etags can be annoying at times, especially in > combination with other
    backends. This patch should improve the > situation, by allowing the user
    to configure how and when the et [...] 
 
 Content analysis details:   (2.7 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [209.85.208.193 listed in wl.mailspike.net]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [209.85.208.193 listed in list.dnswl.org]
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [94.229.108.16 listed in zen.spamhaus.org]
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (dgutov[at]yandex.ru)
  0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
                             mail domains are different
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
  0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and
                             EnvelopeFrom freemail headers are
                             different
 -0.1 NICE_REPLY_A           Looks like a legit reply (A)

Hi!

On 28.08.2020 15:50, Philip K. wrote:

> the xref backend for etags can be annoying at times, especially in
> combination with other backends. This patch should improve the
> situation, by allowing the user to configure how and when the etags
> backend is activated. The new user option etags-query-file would allow
> the backend to never query a TAGS file, or conditionally, depending on
> the existence of a TAGS file (in which case it can also be automatically
> loaded).

This is a interesting patch, but it calls for some discussion:

- The possible values all look pretty clever, but there are a lot of 
them! Do we expect them all to be in demand? Ideally, I'd only leave 2-3 
of them, to reduce the number of workflows we need to care about. The 
rest could probably be set up in individual user configurations in 
find-file-hook (like Projectile does).

- The variable name implies it affects how etags.el works globally, but 
the actual effect seems limited to the xref backend function. We should 
either rename it to something like etags-xref-query-file, or consider 
having it affect tags-completion-at-point-function as well. Maybe 
find-tag too. But given that tags-completion-at-point-function has for a 
long time behaved in the "never query" fashion, perhaps the easiest and 
most backward-compatible option is the former.

- One current persistent annoyance is that currently 
xref-find-references doesn't work well in many files where the xref 
backend is the default one (etags) when ido-mode or icomplete-mode are 
enabled because it prompts for the tags file to do identifier 
completion. I wonder if the "no query" option will help with this, too.

> I could imagine this might be extended to allow an auto-generate option,
> but that feature seems out of scope of this patch, and probably would
> require some interoperation with project.el.

Indeed. Actually, I have an old, WIP patch for tag file auto-generation 
which, yes, uses project.el. I can post it again if you're curious.

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#43086: [PATCH] Allow tags backend to not query for TAGS file
References: <87k0xjue75.fsf@HIDDEN>
Resent-From: "Philip K." <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 06 Sep 2020 21:52:02 +0000
Resent-Message-ID: <handler.43086.B43086.159942906314355 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 43086 <at> debbugs.gnu.org
From: "Philip K." <philipk@HIDDEN>
In-Reply-To: <cfd9096b-6787-236e-7780-df2aa63a94d3@HIDDEN> (message from
 Dmitry Gutov on Sat, 5 Sep 2020 03:45:17 +0300)
Date: Sun, 06 Sep 2020 23:50:54 +0200
Message-ID: <87d02yefr5.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Dmitry Gutov <dgutov@HIDDEN> writes:

> Hi!
>
> On 28.08.2020 15:50, Philip K. wrote:
>
>> the xref backend for etags can be annoying at times, especially in
>> combination with other backends. This patch should improve the
>> situation, by allowing the user to configure how and when the etags
>> backend is activated. The new user option etags-query-file would allow
>> the backend to never query a TAGS file, or conditionally, depending on
>> the existence of a TAGS file (in which case it can also be automatically
>> loaded).
>
> This is a interesting patch, but it calls for some discussion:
>
> - The possible values all look pretty clever, but there are a lot of 
> them! Do we expect them all to be in demand? Ideally, I'd only leave 2-3 
> of them, to reduce the number of workflows we need to care about.

I'm ok with that, the variable could also be turned into a hook if
reducing preconfigured options while making it easy to add new
behaviours.

> The rest could probably be set up in individual user configurations in
> find-file-hook (like Projectile does).

I'm not familiar with how Projectile does this, or how this would work
in general? Could you give an example?

> - The variable name implies it affects how etags.el works globally, but 
> the actual effect seems limited to the xref backend function. We should 
> either rename it to something like etags-xref-query-file, or consider 
> having it affect tags-completion-at-point-function as well.

I'm fine with either, but the first option seems simpler, unless there
is still interest in maintaining the non-xref interface.

> - One current persistent annoyance is that currently 
> xref-find-references doesn't work well in many files where the xref 
> backend is the default one (etags) when ido-mode or icomplete-mode are 
> enabled because it prompts for the tags file to do identifier 
> completion. I wonder if the "no query" option will help with this, too.

Unless I'm misunderstanding something, that's exactly the situation
that motivated me to write these patches (just because of Ivy not Ido).

>> I could imagine this might be extended to allow an auto-generate option,
>> but that feature seems out of scope of this patch, and probably would
>> require some interoperation with project.el.
>
> Indeed. Actually, I have an old, WIP patch for tag file auto-generation 
> which, yes, uses project.el. I can post it again if you're curious.

Sure, why not?

-- 
	Philip K.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43086: [PATCH] Allow tags backend to not query for TAGS file
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 16 Sep 2020 10:54:01 +0000
Resent-Message-ID: <handler.43086.B43086.16002536393102 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43086
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: "Philip K." <philipk@HIDDEN>
Cc: 43086 <at> debbugs.gnu.org
Received: via spool by 43086-submit <at> debbugs.gnu.org id=B43086.16002536393102
          (code B ref 43086); Wed, 16 Sep 2020 10:54:01 +0000
Received: (at 43086) by debbugs.gnu.org; 16 Sep 2020 10:53:59 +0000
Received: from localhost ([127.0.0.1]:33347 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kIV4Z-0000ny-01
	for submit <at> debbugs.gnu.org; Wed, 16 Sep 2020 06:53:59 -0400
Received: from mail-lj1-f196.google.com ([209.85.208.196]:35616)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1kIV4U-0000ni-Lj
 for 43086 <at> debbugs.gnu.org; Wed, 16 Sep 2020 06:53:57 -0400
Received: by mail-lj1-f196.google.com with SMTP id a15so5546517ljk.2
 for <43086 <at> debbugs.gnu.org>; Wed, 16 Sep 2020 03:53:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language;
 bh=WT3R+nuzcW4G+qXPJwXKEoBrFBOXIkk/kc4nSNFComo=;
 b=gFQqQghXhJ1UdxcKoqbtBp2ofhCzKmEXyGnl6w6LIq8fTomi1it74TR62sOvm5/VHw
 yE7R6mxcSKaiTNM8W3O70Nv/igBbIU+TnAcy+Sbx8Gkue2APOJEwCematDhxoWO+lrSX
 WkfO+xQbcmB2xAKYDUkPsGVQV7wUYy0GhCGAn4Az3IN89G7SFYXcG4eXHouKfJ3rB31A
 mXYhp6SijlQcJ8156bABGex07OZHKuMV5OCIFAbNTW4ketyrI+wJQl/Cw5lnfxfYCUTL
 eEdso6vyYqzMebPpC38F7wr6HPry5ea0By1oBaVxfFokogizCmN3PaiyFgWDNpfIWhEk
 4H8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language;
 bh=WT3R+nuzcW4G+qXPJwXKEoBrFBOXIkk/kc4nSNFComo=;
 b=UMlcQwKZTgwHYLbnmrcBGB56/7p2HE5qTiZGu+RPcX1BvoXnU2eVeGqNMKRvDxyWe6
 JGEX4SoPkNRQilY4lAf6A1XnYFcUPrpAU6J5t6jawbr7XrysAwPHScDnmgpwAix6r5wr
 7ffbcgF1Z8uphMqcX0n5vD36I+KR6TwOtebyuNvIIrBWXlbmaAYLY4zgZsgIzsFEYdYL
 JaO8V5e4vNB0+pW1lR7B7y030AtdInGArf32Kv3DiJc6/nizgjWi+txWrv9tzxt0//OM
 Xj2JwmuI1JY/IcgX+HdHeDKImrR7zoH2wJIxU8agSaepDaDTT+Ip2Vi9fntr6UOlZiMp
 nBEg==
X-Gm-Message-State: AOAM532auVontSyQzKkBkrn3AbbANjD/p61e5qjj+Uvs292dTfa5b0VX
 4gOtN65v7nUVu+YD9arzxTTPhQurzMQ=
X-Google-Smtp-Source: ABdhPJyKOOjMKB0zCXe9GNmtA8ninklQffuhgSYiWtTJB21d6IAU+zdPV9MZAmcSTJeVWq7StMBdTA==
X-Received: by 2002:a2e:b174:: with SMTP id a20mr8061560ljm.407.1600253628153; 
 Wed, 16 Sep 2020 03:53:48 -0700 (PDT)
Received: from [192.168.0.104] ([94.229.108.16])
 by smtp.googlemail.com with ESMTPSA id e9sm4495268lfn.237.2020.09.16.03.53.46
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 16 Sep 2020 03:53:47 -0700 (PDT)
References: <87d02yefr5.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <f225337a-23d4-0aaf-a178-1fe1f9826749@HIDDEN>
Date: Wed, 16 Sep 2020 13:53:46 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <87d02yefr5.fsf@HIDDEN>
Content-Type: multipart/mixed; boundary="------------10F7F4AC33FDB703B10FCBB2"
Content-Language: en-US
X-Spam-Score: 0.4 (/)
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.6 (/)

This is a multi-part message in MIME format.
--------------10F7F4AC33FDB703B10FCBB2
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 07.09.2020 00:50, Philip K. wrote:
> Dmitry Gutov <dgutov@HIDDEN> writes:
> 
>> Hi!
>>
>> On 28.08.2020 15:50, Philip K. wrote:
>>
>>> the xref backend for etags can be annoying at times, especially in
>>> combination with other backends. This patch should improve the
>>> situation, by allowing the user to configure how and when the etags
>>> backend is activated. The new user option etags-query-file would allow
>>> the backend to never query a TAGS file, or conditionally, depending on
>>> the existence of a TAGS file (in which case it can also be automatically
>>> loaded).
>>
>> This is a interesting patch, but it calls for some discussion:
>>
>> - The possible values all look pretty clever, but there are a lot of
>> them! Do we expect them all to be in demand? Ideally, I'd only leave 2-3
>> of them, to reduce the number of workflows we need to care about.
> 
> I'm ok with that, the variable could also be turned into a hook if
> reducing preconfigured options while making it easy to add new
> behaviours.

Not sure how the direct conversion to a hook would look like.

In any case, when I talked about using a hook (find-file-hook in 
particular), the main benefit I had in mind is that the effect would 
cover all uses of etags.el. Meaning, also tags-completion-at-point-function.

>> The rest could probably be set up in individual user configurations in
>> find-file-hook (like Projectile does).
> 
> I'm not familiar with how Projectile does this, or how this would work
> in general? Could you give an example?

projectile-mode adds projectile-find-file-hook-function to 
find-file-hook, which, upon visiting any file, looks for 
projectile-tags-file-name (usually "TAGS")'s presence in the root of the 
project. When such file exists, it calls (visit-tags-table tags-file t), 
to visit the tags table "locally".

Since project.el does not have a minor mode, and out of general 
(admittedly handwavy) considerations of performance, we don't do that. 
But a user could customize their find-file-hook with a similar logic. If 
you like, you could also add a pre-existing function like that to 
project.el that a user could then just add to find-file-hook.

>> - The variable name implies it affects how etags.el works globally, but
>> the actual effect seems limited to the xref backend function. We should
>> either rename it to something like etags-xref-query-file, or consider
>> having it affect tags-completion-at-point-function as well.
> 
> I'm fine with either, but the first option seems simpler, unless there
> is still interest in maintaining the non-xref interface.

There might be some other benefit to the latter, but it doesn't seem 
trivial, so the former sounds fine to me as well.

>> - One current persistent annoyance is that currently
>> xref-find-references doesn't work well in many files where the xref
>> backend is the default one (etags) when ido-mode or icomplete-mode are
>> enabled because it prompts for the tags file to do identifier
>> completion. I wonder if the "no query" option will help with this, too.
> 
> Unless I'm misunderstanding something, that's exactly the situation
> that motivated me to write these patches (just because of Ivy not Ido).

I set etags-query-file to nil and call xref-find-references with 
ido-mode enabled. And still get queried for a tags file.

Because etags--xref-backend still returns 'etags, but then 
xref-backend-identifier-completion-table calls 
tags-lazy-completion-table, which does the prompting.

If I make etags--xref-backend return nil, I simply get "No applicable 
method: xref-backend-identifier-completion-table, nil" instead.

So a deeper change is needed.

>>> I could imagine this might be extended to allow an auto-generate option,
>>> but that feature seems out of scope of this patch, and probably would
>>> require some interoperation with project.el.
>>
>> Indeed. Actually, I have an old, WIP patch for tag file auto-generation
>> which, yes, uses project.el. I can post it again if you're curious.
> 
> Sure, why not?

Here it is. It might even be functional.

The reason it's not installed yet, is I was looking to create a seamless 
user experience with it, when they don't need to know which tags file is 
visited, and when. And with tags being quickly updated after a file is 
changed and saved.

The related discussion about necessary changes to etags fizzled out, 
however.

--------------10F7F4AC33FDB703B10FCBB2
Content-Type: text/x-patch; charset=UTF-8;
 name="etags-project.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="etags-project.diff"

diff --git a/lisp/progmodes/etags.el b/lisp/progmodes/etags.el
index a31668e1ba..9da2143525 100644
--- a/lisp/progmodes/etags.el
+++ b/lisp/progmodes/etags.el
@@ -2109,7 +2109,9 @@ etags-xref-find-definitions-tag-order
   "Tag order used in `xref-backend-definitions' to look for definitions.")
 
 ;;;###autoload
-(defun etags--xref-backend () 'etags)
+(defun etags--xref-backend ()
+  (etags--maybe-use-project-tags)
+  'etags)
 
 (cl-defmethod xref-backend-identifier-at-point ((_backend (eql etags)))
   (find-tag--default))
@@ -2180,6 +2182,58 @@ xref-make-etags-location
     (nth 1 tag-info)))
 
 
+;;; Simple tags generation, with automatic invalidation
+
+(defvar etags--project-tags-file nil)
+(defvar etags--project-tags-root nil)
+
+(defun etags--maybe-use-project-tags ()
+  (let (proj)
+    (when (and etags--project-tags-root
+               (not (file-in-directory-p default-directory
+                                         etags--project-tags-root)))
+      (etags--project-tags-cleanup))
+    (when (and (not (or tags-file-name
+                        tags-table-list))
+               (setq proj (project-current)))
+      (etags--project-tags-generate proj)
+      ;; Invalidate the scanned tags after any change is written to disk.
+      (add-hook 'after-save-hook #'etags--project-tags-cleanup)
+      (visit-tags-table etags--project-tags-file))))
+
+(defun etags--project-tags-generate (proj)
+  (let* ((root (cl-find default-directory
+                        (project-roots proj)
+                        :test #'file-in-directory-p))
+         (default-directory root)
+         (files (all-completions "" (project-file-completion-table proj (list root))))
+         (etags-command (executable-find "etags"))
+         ;; FIXME: List all extensions, or wait for etags fix.
+         ;; http://lists.gnu.org/archive/html/emacs-devel/2018-01/msg00323.html
+         (extensions '("rb" "js" "py" "pl" "el" "c" "cpp" "cc" "h" "hh" "hpp"
+                       "java" "go" "cl" "lisp" "prolog" "php" "erl" "hrl"
+                       "F" "f" "f90" "for" "cs" "a" "asm" "ads" "adb" "ada"))
+         (file-regexp (format "\\.%s\\'" (regexp-opt extensions))))
+    (setq etags--project-tags-file (make-temp-file "emacs-project-tags-")
+          etags--project-tags-root root)
+    (with-temp-buffer
+      (mapc (lambda (f)
+              (when (string-match-p file-regexp f)
+                (insert f "\n")))
+            files)
+      (shell-command-on-region (point-min) (point-max)
+                               (format "%s - -o %s" etags-command etags--project-tags-file)
+                               nil nil "*etags-project-tags-errors*" t))))
+
+(defun etags--project-tags-cleanup ()
+  (when etags--project-tags-file
+    (delete-file etags--project-tags-file)
+    (setq tags-file-name nil
+          tags-table-list nil
+          etags--project-tags-file nil
+          etags--project-tags-root nil))
+  (remove-hook 'after-save-hook #'etags--project-tags-cleanup))
+
 (provide 'etags)
 
 ;;; etags.el ends here

--------------10F7F4AC33FDB703B10FCBB2--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43086: [PATCH] Allow tags backend to not query for TAGS file
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 12 Nov 2021 08:26:02 +0000
Resent-Message-ID: <handler.43086.B43086.163670555632409 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43086
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: "Philip K." <philipk@HIDDEN>, 43086 <at> debbugs.gnu.org
Received: via spool by 43086-submit <at> debbugs.gnu.org id=B43086.163670555632409
          (code B ref 43086); Fri, 12 Nov 2021 08:26:02 +0000
Received: (at 43086) by debbugs.gnu.org; 12 Nov 2021 08:25:56 +0000
Received: from localhost ([127.0.0.1]:43388 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mlRsi-0008Qf-GI
	for submit <at> debbugs.gnu.org; Fri, 12 Nov 2021 03:25:56 -0500
Received: from quimby.gnus.org ([95.216.78.240]:34844)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1mlRsg-0008QS-Dy
 for 43086 <at> debbugs.gnu.org; Fri, 12 Nov 2021 03:25:55 -0500
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:In-Reply-To:Date:
 References: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=PlMOEx0PBhLQvVFtZlyzkYCcPKvpQ4HZGbtOgbfJINA=; b=W110D3bybfY380R6VQHbSCO016
 g0xBndVBmijqH8io/wgMrZsA56t3dPNviAhyOOdQh/1ZNv6QFMpzwES1NPU53Ztvu+RyuWFCbTc49
 KlXlzrNnSjSJLbAbWKWX9idKZWef920kxyNXQ1hnXcNQ+c7Mr3DY+oTBatoMdVM11t7A=;
Received: from [84.212.220.105] (helo=xo)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1mlRsY-0005i4-2v; Fri, 12 Nov 2021 09:25:48 +0100
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <87d02yefr5.fsf@HIDDEN>
 <f225337a-23d4-0aaf-a178-1fe1f9826749@HIDDEN>
X-Now-Playing: Sonic Youth's _NYC Ghosts & Flowers_: "NYC Ghosts & Flowers"
Date: Fri, 12 Nov 2021 09:25:45 +0100
In-Reply-To: <f225337a-23d4-0aaf-a178-1fe1f9826749@HIDDEN> (Dmitry Gutov's
 message of "Wed, 16 Sep 2020 13:53:46 +0300")
Message-ID: <87r1blu6eu.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: >>> - The possible
 values all look pretty clever, but there are a lot of >>> them! Do we expect
 them all to be in demand? Ideally, I'd only leave 2-3 >>> of them, to reduce
 the number of workflows we [...] 
 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-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:

>>> - The possible values all look pretty clever, but there are a lot of
>>> them! Do we expect them all to be in demand? Ideally, I'd only leave 2-3
>>> of them, to reduce the number of workflows we need to care about.
>> I'm ok with that, the variable could also be turned into a hook if
>> reducing preconfigured options while making it easy to add new
>> behaviours.
>
> Not sure how the direct conversion to a hook would look like.
>
> In any case, when I talked about using a hook (find-file-hook in
> particular), the main benefit I had in mind is that the effect would
> cover all uses of etags.el. Meaning, also
> tags-completion-at-point-function.

This was over a year ago, and it's unclear whether we wanted to do in
Philip's patch's direction or not?  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43086: [PATCH] Allow tags backend to not query for TAGS file
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 14 Nov 2021 00:03:01 +0000
Resent-Message-ID: <handler.43086.B43086.163684814214125 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43086
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 43086 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 43086-submit <at> debbugs.gnu.org id=B43086.163684814214125
          (code B ref 43086); Sun, 14 Nov 2021 00:03:01 +0000
Received: (at 43086) by debbugs.gnu.org; 14 Nov 2021 00:02:22 +0000
Received: from localhost ([127.0.0.1]:48491 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mm2yU-0003fj-0Y
	for submit <at> debbugs.gnu.org; Sat, 13 Nov 2021 19:02:22 -0500
Received: from mout01.posteo.de ([185.67.36.65]:57745)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1mm2yP-0003fP-43
 for 43086 <at> debbugs.gnu.org; Sat, 13 Nov 2021 19:02:20 -0500
Received: from submission (posteo.de [89.146.220.130]) 
 by mout01.posteo.de (Postfix) with ESMTPS id C9FB9240027
 for <43086 <at> debbugs.gnu.org>; Sun, 14 Nov 2021 01:02:10 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1636848130; bh=7fr3Nyo3kaQZHalZ2hHr6n7v4ccxwk1S8ED03j/lLSo=;
 h=From:To:Cc:Subject:Autocrypt:Date:From;
 b=oBG9FNpHDqeafuUbeEnEnp1MLlD4JWZsQRiyvPTuIBc8n+q4DS+43t/989GjY7j23
 SSKah4Mg8kPEsDR+5Vc6MnV56VoVK5mwd0n3Hg9issYpZC0ogcrbTbtNa8pSaBjMrU
 32UoiPX2ltfE6tqvJ0bw5nQZCF+V5sZojZUgnd17E1HDq1QwCucE+l7n9OofrfLxwO
 2TO4dAMPbw2sqC9znP5XEDUuHU9m8VTN9lLAkl2iY26xkvAD1fdKiKsx2Mer58NGpN
 wJ6J5JOaxnU0SJDvK5mWaqUKo/HAykFwH0J637fOUQSYyFIe/tGDHysO8RUqw4bYxe
 UgcmoZEk+cFvA==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4HsCDd3vnfz9rwg;
 Sun, 14 Nov 2021 01:02:09 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
References: <87d02yefr5.fsf@HIDDEN>
 <f225337a-23d4-0aaf-a178-1fe1f9826749@HIDDEN>
 <87r1blu6eu.fsf@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Sun, 14 Nov 2021 00:02:08 +0000
In-Reply-To: <87r1blu6eu.fsf@HIDDEN> (Lars Ingebrigtsen's message of "Fri,
 12 Nov 2021 09:25:45 +0100")
Message-ID: <87v90veha7.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
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 (---)

Lars Ingebrigtsen <larsi@HIDDEN> writes:

> Dmitry Gutov <dgutov@HIDDEN> writes:
>
>>>> - The possible values all look pretty clever, but there are a lot of
>>>> them! Do we expect them all to be in demand? Ideally, I'd only leave 2-3
>>>> of them, to reduce the number of workflows we need to care about.
>>> I'm ok with that, the variable could also be turned into a hook if
>>> reducing preconfigured options while making it easy to add new
>>> behaviours.
>>
>> Not sure how the direct conversion to a hook would look like.
>>
>> In any case, when I talked about using a hook (find-file-hook in
>> particular), the main benefit I had in mind is that the effect would
>> cover all uses of etags.el. Meaning, also
>> tags-completion-at-point-function.
>
> This was over a year ago, and it's unclear whether we wanted to do in
> Philip's patch's direction or not?  

What exactly was the issue with my suggestion?

-- 
	Philip Kaludercic

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43086: [PATCH] Allow tags backend to not query for TAGS file
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 11 Sep 2022 11:37:01 +0000
Resent-Message-ID: <handler.43086.B43086.166289620122605 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43086
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Philip Kaludercic <philipk@HIDDEN>
Cc: 43086 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 43086-submit <at> debbugs.gnu.org id=B43086.166289620122605
          (code B ref 43086); Sun, 11 Sep 2022 11:37:01 +0000
Received: (at 43086) by debbugs.gnu.org; 11 Sep 2022 11:36:41 +0000
Received: from localhost ([127.0.0.1]:40975 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oXLGT-0005sX-4Q
	for submit <at> debbugs.gnu.org; Sun, 11 Sep 2022 07:36:41 -0400
Received: from quimby.gnus.org ([95.216.78.240]:39638)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1oXLGR-0005sE-KE
 for 43086 <at> debbugs.gnu.org; Sun, 11 Sep 2022 07:36:40 -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=DRsrnBG4W1eYtbZXKpjYsJv5nBnXBENxiRmkKvwJh7w=; b=CMxHwv0b21sS7UJQG86Sgrlfw9
 3z7bxjVir7crArI+lNEWdohtIhZEMLR1CGLkIhGIOG0PWCMB+bE8TSHKTq7j/4yDQJueyw4TPFFry
 hbCfPxF6Bf+e7IlsgPmFELvrNKS6xsuHN+VBBJ0B0Bf/DlGCA0S4qChTuEXRDymQXQZs=;
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 1oXLGJ-0003vt-FM; Sun, 11 Sep 2022 13:36:33 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
In-Reply-To: <87v90veha7.fsf@HIDDEN> (Philip Kaludercic's message of "Sun, 
 14 Nov 2021 00:02:08 +0000")
References: <87d02yefr5.fsf@HIDDEN>
 <f225337a-23d4-0aaf-a178-1fe1f9826749@HIDDEN>
 <87r1blu6eu.fsf@HIDDEN> <87v90veha7.fsf@HIDDEN>
X-Now-Playing: Insides's _Euphoria_: "Further Distractions"
Date: Sun, 11 Sep 2022 13:36:30 +0200
Message-ID: <87edwif8ht.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:  Philip Kaludercic <philipk@HIDDEN> writes: >> This was
 over a year ago, and it's unclear whether we wanted to do in >> Philip's
 patch's direction or not? > > What exactly was the issue with my suggestion?
 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-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 (---)

Philip Kaludercic <philipk@HIDDEN> writes:

>> This was over a year ago, and it's unclear whether we wanted to do in
>> Philip's patch's direction or not?  
>
> What exactly was the issue with my suggestion?

Dmitry said:

> I set etags-query-file to nil and call xref-find-references with
> ido-mode enabled. And still get queried for a tags file.
> 
> Because etags--xref-backend still returns 'etags, but then
> xref-backend-identifier-completion-table calls
> tags-lazy-completion-table, which does the prompting.
> 
> If I make etags--xref-backend return nil, I simply get "No applicable
> method: xref-backend-identifier-completion-table, nil" instead.
> 
> So a deeper change is needed.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43086: [PATCH] Allow tags backend to not query for TAGS file
Resent-From: Richard Stallman <rms@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 13 Sep 2022 04:08:02 +0000
Resent-Message-ID: <handler.43086.B43086.16630420465312 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43086
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: philipk@HIDDEN, 43086 <at> debbugs.gnu.org, dgutov@HIDDEN
Reply-To: rms@HIDDEN
Received: via spool by 43086-submit <at> debbugs.gnu.org id=B43086.16630420465312
          (code B ref 43086); Tue, 13 Sep 2022 04:08:02 +0000
Received: (at 43086) by debbugs.gnu.org; 13 Sep 2022 04:07:26 +0000
Received: from localhost ([127.0.0.1]:48511 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oXxCo-0001Nc-6U
	for submit <at> debbugs.gnu.org; Tue, 13 Sep 2022 00:07:26 -0400
Received: from eggs.gnu.org ([209.51.188.92]:53642)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rms@HIDDEN>) id 1oXxCh-0001NK-Db
 for 43086 <at> debbugs.gnu.org; Tue, 13 Sep 2022 00:07:24 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:36798)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <rms@HIDDEN>)
 id 1oXxCb-0004yZ-VX; Tue, 13 Sep 2022 00:07:13 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From:
 mime-version; bh=gunhiVUFAxiwjg2U2qoF1uYERJrMUSRDa08+ICsf2b0=; b=SXJTWrtw/fHq
 gGBQ7Tlik/6K21xjYkbKtLd7Kcv9eJUShmxsXnImAPewnqhiCPByRTke7h3ba2e2UFkhmhyaBV0F6
 fWZTZa34Z7AThujkATdNUyyWk74GcTB08fuzoHbiTqYMAexWarQU+oeusb5OedEKQh2rBzRIbKsjE
 qM58oNKS/GEAANyp2RRo+1U3gFlNFkzZaYP+P+aRlM/IRHDZdMpDW1OHnhZvcgvGJzyJGRnh6jbAu
 HbyeNK8WwGzHtKAhXI0snBOEw0YbcUSh7qE+XhUScbyUJa3EF1KaYK6AhSipKYXrDlHuyGbFFzsuS
 HKT7391qY7E/cPHm8ReVhw==;
Received: from rms by fencepost.gnu.org with local (Exim 4.90_1)
 (envelope-from <rms@HIDDEN>)
 id 1oXxCb-0006im-Lh; Tue, 13 Sep 2022 00:07:13 -0400
Content-Type: text/plain; charset=Utf-8
From: Richard Stallman <rms@HIDDEN>
In-Reply-To: <87edwif8ht.fsf@HIDDEN> (message from Lars Ingebrigtsen on Sun, 
 11 Sep 2022 13:36:30 +0200)
References: <87d02yefr5.fsf@HIDDEN>
 <f225337a-23d4-0aaf-a178-1fe1f9826749@HIDDEN>
 <87r1blu6eu.fsf@HIDDEN> <87v90veha7.fsf@HIDDEN>
 <87edwif8ht.fsf@HIDDEN>
Message-Id: <E1oXxCb-0006im-Lh@HIDDEN>
Date: Tue, 13 Sep 2022 00:07:13 -0400
X-Spam-Score: -2.3 (--)
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 (---)

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

if we want to support a decision not to query, is it clear that this
decision should be determined by the choice of back end>?
Might it be, rather, a personal preference?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43086: [PATCH] Allow tags backend to not query for TAGS file
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 03 Sep 2024 16:42:02 +0000
Resent-Message-ID: <handler.43086.B43086.17253816685358 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43086
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 43086 <at> debbugs.gnu.org
Received: via spool by 43086-submit <at> debbugs.gnu.org id=B43086.17253816685358
          (code B ref 43086); Tue, 03 Sep 2024 16:42:02 +0000
Received: (at 43086) by debbugs.gnu.org; 3 Sep 2024 16:41:08 +0000
Received: from localhost ([127.0.0.1]:60720 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1slWaa-0001OL-4n
	for submit <at> debbugs.gnu.org; Tue, 03 Sep 2024 12:41:08 -0400
Received: from mout01.posteo.de ([185.67.36.65]:35285)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1slWaX-0001Nh-AD
 for 43086 <at> debbugs.gnu.org; Tue, 03 Sep 2024 12:41:06 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id 61C36240027
 for <43086 <at> debbugs.gnu.org>; Tue,  3 Sep 2024 18:39:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1725381596; bh=g2DvE0RJQqVdFVW3V0CBEtakM/qACLQfX7getn1+7jk=;
 h=From:To:Cc:Subject:Autocrypt:OpenPGP:Date:Message-ID:MIME-Version:
 Content-Type:From;
 b=Fc4URAgw4vvYqq3UFwy0R8Ufvv6wD666Uo3dHUaWt64Qf+uNbv/1GJZCItQAjwcuP
 V+t6CQHtHKryOpBFr5iieuV1wjisZRsg5R9CfjXczFiZvDmh5t69CEedvlJqMOYasp
 b0CrxgOA1ZGLSFTROZhbtHjUKcfQ6CmEKEsgdaxJMzLqetoEDcePZ67GyLUpGLKESz
 iICq1Ah0alrmCSuNXdzeBEBIZtit3UN41dBNyE9Nl7zRV2LGOeFYrsJ7xjv7YEgWmr
 nzq35I3j9S1CAUpUKHhKLfCN3bcsxAHpUvbgbpFBJ8k7xG98H4pPudz5KPTh7J8KWR
 3KXRjVjQhY+9g==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4WyrvH6Cs6z6tm4;
 Tue,  3 Sep 2024 18:39:55 +0200 (CEST)
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <cfd9096b-6787-236e-7780-df2aa63a94d3@HIDDEN> (Dmitry Gutov's
 message of "Sat, 5 Sep 2020 03:45:17 +0300")
References: <87k0xjue75.fsf@HIDDEN>
 <cfd9096b-6787-236e-7780-df2aa63a94d3@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; keydata=
 mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI
 BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0
 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB
 BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE
 Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK
 NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof
 z4oM
OpenPGP: id=philipk@HIDDEN;
 url="https://keys.openpgp.org/vks/v1/by-email/philipk@HIDDEN";
 preference=signencrypt
Date: Tue, 03 Sep 2024 16:39:55 +0000
Message-ID: <87zfoog084.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
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:

> Hi!
>
> On 28.08.2020 15:50, Philip K. wrote:
>
>> the xref backend for etags can be annoying at times, especially in
>> combination with other backends. This patch should improve the
>> situation, by allowing the user to configure how and when the etags
>> backend is activated. The new user option etags-query-file would allow
>> the backend to never query a TAGS file, or conditionally, depending on
>> the existence of a TAGS file (in which case it can also be automatically
>> loaded).
>
> This is a interesting patch, but it calls for some discussion:
>
> - The possible values all look pretty clever, but there are a lot of
>   them! Do we expect them all to be in demand? Ideally, I'd only leave
>   2-3 of them, to reduce the number of workflows we need to care
>   about. The rest could probably be set up in individual user
>   configurations in find-file-hook (like Projectile does).
>
> - The variable name implies it affects how etags.el works globally,
>   but the actual effect seems limited to the xref backend function. We
>   should either rename it to something like etags-xref-query-file, or
>   consider having it affect tags-completion-at-point-function as
>   well. Maybe find-tag too. But given that
>   tags-completion-at-point-function has for a long time behaved in the
>   "never query" fashion, perhaps the easiest and most
>  backward-compatible option is the former.
>
> - One current persistent annoyance is that currently
>   xref-find-references doesn't work well in many files where the xref
>   backend is the default one (etags) when ido-mode or icomplete-mode
>   are enabled because it prompts for the tags file to do identifier
>   completion. I wonder if the "no query" option will help with this,
>  too.
>
>> I could imagine this might be extended to allow an auto-generate option,
>> but that feature seems out of scope of this patch, and probably would
>> require some interoperation with project.el.
>
> Indeed. Actually, I have an old, WIP patch for tag file
> auto-generation which, yes, uses project.el. I can post it again if
> you're curious.

Hasn't this issue been resolved by `etags-regen-mode'?

-- 
	Philip Kaludercic on peregrine

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43086: [PATCH] Allow tags backend to not query for TAGS file
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 06 Sep 2024 22:26:02 +0000
Resent-Message-ID: <handler.43086.B43086.172566150215768 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43086
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Philip Kaludercic <philipk@HIDDEN>
Cc: 43086 <at> debbugs.gnu.org
Received: via spool by 43086-submit <at> debbugs.gnu.org id=B43086.172566150215768
          (code B ref 43086); Fri, 06 Sep 2024 22:26:02 +0000
Received: (at 43086) by debbugs.gnu.org; 6 Sep 2024 22:25:02 +0000
Received: from localhost ([127.0.0.1]:54341 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1smhO1-00046B-Us
	for submit <at> debbugs.gnu.org; Fri, 06 Sep 2024 18:25:02 -0400
Received: from forward500a.mail.yandex.net ([178.154.239.80]:44428)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dgutov@HIDDEN>) id 1smhNy-00045n-Mh
 for 43086 <at> debbugs.gnu.org; Fri, 06 Sep 2024 18:25:00 -0400
Received: from mail-nwsmtp-smtp-production-main-54.vla.yp-c.yandex.net
 (mail-nwsmtp-smtp-production-main-54.vla.yp-c.yandex.net
 [IPv6:2a02:6b8:c15:2c8f:0:640:f9cc:0])
 by forward500a.mail.yandex.net (Yandex) with ESMTPS id D2E62610C1;
 Sat,  7 Sep 2024 01:16:51 +0300 (MSK)
Received: by mail-nwsmtp-smtp-production-main-54.vla.yp-c.yandex.net
 (smtp/Yandex) with ESMTPSA id nGn3v734UW20-tCECyfGF; 
 Sat, 07 Sep 2024 01:16:51 +0300
X-Yandex-Fwd: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail;
 t=1725661011; bh=z7f/X7J8cTo7lPpf68AxJbjKNJ3M1BuG8t8L7aUdKw0=;
 h=In-Reply-To:From:Subject:Message-ID:Cc:References:Date:To;
 b=IxH27GJb36WmwfUgrDtr8VzVHjxge0CUL87T43cmoB0CQLUVgK+C8SkOMNEMdPZD9
 aej+7vubmpqGcJraCdGlxqM/DLhIMALdUvNXZzmlnwPkZhQD7MsCYU492WYEmeKqd5
 5huEG9hhUMfpRtDRWoqN+twGqDFxrTcIhAj4bIdw=
Authentication-Results: mail-nwsmtp-smtp-production-main-54.vla.yp-c.yandex.net;
 dkim=pass header.i=@yandex.ru
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfauth.phl.internal (Postfix) with ESMTP id 3A5F9120006C;
 Fri,  6 Sep 2024 18:16:48 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-06.internal (MEProxy); Fri, 06 Sep 2024 18:16:49 -0400
X-ME-Sender: <xms:UH_bZv0loqBpzhsxX2hj2u3RcyLO01XsJfjCMJrNo2CuN2GqBG65zw>
 <xme:UH_bZuGWXcapnF5ZgKDLW1XxnmI4en-_uZAr5EjqZ8fi4dl6M3CpX9CZFVZvbMLyG
 W3tYNR5kxPB_HXe4R4>
X-ME-Received: <xmr:UH_bZv67M7hJKSLBQC5zgSy_JMmATHUEUSW_veCm3nFkNmC8d5FtLbkVAnOoDnipeTS9>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudeivddgtdekucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
 rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
 htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdej
 necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegughhuthhovheshigrnhguvgigrd
 hruheqnecuggftrfgrthhtvghrnhepiefhjeeuveetffffvdefteffffekhfeuudejieeh
 heeiudelgfehgffffeduffdunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe
 hmrghilhhfrhhomhepughguhhtohhvodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhi
 thihqddufeeffeelleehhedvqddvleegjeejjeejiedqughguhhtohhvpeephigrnhguvg
 igrdhruhesfhgrshhtmhgrihhlrdgtohhmpdhnsggprhgtphhtthhopedvpdhmohguvgep
 shhmthhpohhuthdprhgtphhtthhopehphhhilhhiphhksehpohhsthgvohdrnhgvthdprh
 gtphhtthhopeegfedtkeeiseguvggssghughhsrdhgnhhurdhorhhg
X-ME-Proxy: <xmx:UH_bZk2r-L-KbReQujrcmul96mgsakVvqMqkroKg7biW2bH4fjqfdA>
 <xmx:UH_bZiHiBxQZkb6mmTNjUsNuPl_wHCLnSfy2U1RhqlmKSy2XJVpWOQ>
 <xmx:UH_bZl-K1zE0xB9A-0TCYO4s1KN4OGft7QnDKhdx4qDSUXSb3amSxg>
 <xmx:UH_bZvnVSEMQAVtb19UpVOuM8KxDQG643AeubE4tVRUYiofLKoM3AA>
 <xmx:UH_bZuGdfU583_Gl4wnjpTQyG7ltBSey6dSn2g376KomhD6Tg0anb82i>
Feedback-ID: ib1d9465d:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 6 Sep 2024 18:16:47 -0400 (EDT)
Message-ID: <ef6452be-d2d2-40f9-9302-d3c7c245f3ce@HIDDEN>
Date: Sat, 7 Sep 2024 01:16:46 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <87k0xjue75.fsf@HIDDEN>
 <cfd9096b-6787-236e-7780-df2aa63a94d3@HIDDEN> <87zfoog084.fsf@HIDDEN>
Content-Language: en-US
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <87zfoog084.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.0 (/)
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 03/09/2024 19:39, Philip Kaludercic wrote:
>>> I could imagine this might be extended to allow an auto-generate option,
>>> but that feature seems out of scope of this patch, and probably would
>>> require some interoperation with project.el.
>> Indeed. Actually, I have an old, WIP patch for tag file
>> auto-generation which, yes, uses project.el. I can post it again if
>> you're curious.
> Hasn't this issue been resolved by `etags-regen-mode'?

The part quoted above was, I think.

What might still be missing, is functioning better without having a tags 
table generated - after all etags-regen-mode is off by default, and it 
might not work for certain projects anyway.

Maybe just like this? This makes Xref identifier completion not query 
for TAGS unless already loaded. In many cases that would be TRT, 
although `C-u M-.` seems to regress (seems like we *would* want to query 
eagerly there).

Adding a user option is still... an option.

diff --git a/lisp/progmodes/etags.el b/lisp/progmodes/etags.el
index d3eb0d46e9b..a4e9abe9b7a 100644
--- a/lisp/progmodes/etags.el
+++ b/lisp/progmodes/etags.el
@@ -2102,7 +2102,9 @@ xref-backend-identifier-at-point

  (cl-defmethod xref-backend-identifier-completion-table ((_backend
                                                           (eql 'etags)))
-  (tags-lazy-completion-table))
+  (and (or tags-file-name
+           tags-table-list)
+       (tags-lazy-completion-table)))

  (cl-defmethod xref-backend-identifier-completion-ignore-case ((_backend
                                                                 (eql 
'etags)))

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43086: [PATCH] Allow tags backend to not query for TAGS file
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 07 Sep 2024 06:54:01 +0000
Resent-Message-ID: <handler.43086.B43086.172569200128499 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43086
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: philipk@HIDDEN, 43086 <at> debbugs.gnu.org
Received: via spool by 43086-submit <at> debbugs.gnu.org id=B43086.172569200128499
          (code B ref 43086); Sat, 07 Sep 2024 06:54:01 +0000
Received: (at 43086) by debbugs.gnu.org; 7 Sep 2024 06:53:21 +0000
Received: from localhost ([127.0.0.1]:54611 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1smpJx-0007PV-1i
	for submit <at> debbugs.gnu.org; Sat, 07 Sep 2024 02:53:21 -0400
Received: from eggs.gnu.org ([209.51.188.92]:37370)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1smpJt-0007OR-Hk
 for 43086 <at> debbugs.gnu.org; Sat, 07 Sep 2024 02:53:18 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1smomW-00065c-3g; Sat, 07 Sep 2024 02:18:48 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=HM3OsgZqlAaUJikbsRdlJJFr6nXK0f8EBL1kowY1p5c=; b=csFIDJin8UvF
 2BmPPixXo/lgLVKZvr8SQLDLxQH0GFs6335kJ6wbHrJ+yIRGaPNlhM4J9oydG9RCYnM6tL9z25Yi+
 RJTMrkSN1tutTv6PSr2wawSboxrZMpuP15Fx7YU+SggMsMRNQ41Bfea5cdWF8WyrKcLmN3pwN4vhB
 UyIImFAR1ijQTTH9+DE7dyL7S9Mf0u60ZYEMsMjjwd/PelPkCDxSbgbUne5q4qVlNN3v+rlZ7fUKm
 OlYdaUmm34k+jOLQwQPQgbL4Z5BirOze9SBu0EYfeDObd5xx0le1IsJM1u40PGSh5wDjWpJGTl1hJ
 nMzjCRMgwguFqOlyB+HNLw==;
Date: Sat, 07 Sep 2024 09:18:46 +0300
Message-Id: <86v7z8yojd.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <ef6452be-d2d2-40f9-9302-d3c7c245f3ce@HIDDEN> (message from
 Dmitry Gutov on Sat, 7 Sep 2024 01:16:46 +0300)
References: <87k0xjue75.fsf@HIDDEN>
 <cfd9096b-6787-236e-7780-df2aa63a94d3@HIDDEN> <87zfoog084.fsf@HIDDEN>
 <ef6452be-d2d2-40f9-9302-d3c7c245f3ce@HIDDEN>
X-Spam-Score: -2.3 (--)
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 (---)

> Cc: 43086 <at> debbugs.gnu.org
> Date: Sat, 7 Sep 2024 01:16:46 +0300
> From: Dmitry Gutov <dgutov@HIDDEN>
> 
> On 03/09/2024 19:39, Philip Kaludercic wrote:
> >>> I could imagine this might be extended to allow an auto-generate option,
> >>> but that feature seems out of scope of this patch, and probably would
> >>> require some interoperation with project.el.
> >> Indeed. Actually, I have an old, WIP patch for tag file
> >> auto-generation which, yes, uses project.el. I can post it again if
> >> you're curious.
> > Hasn't this issue been resolved by `etags-regen-mode'?
> 
> The part quoted above was, I think.
> 
> What might still be missing, is functioning better without having a tags 
> table generated - after all etags-regen-mode is off by default, and it 
> might not work for certain projects anyway.
> 
> Maybe just like this? This makes Xref identifier completion not query 
> for TAGS unless already loaded. In many cases that would be TRT, 
> although `C-u M-.` seems to regress (seems like we *would* want to query 
> eagerly there).

I don't understand why the obvious way of asking the user whether they
would like to generate the tags table is not the solution here.  What
did I miss?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43086: [PATCH] Allow tags backend to not query for TAGS file
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 09 Sep 2024 00:30:02 +0000
Resent-Message-ID: <handler.43086.B43086.172584176023841 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43086
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eli Zaretskii <eliz@HIDDEN>
Cc: philipk@HIDDEN, 43086 <at> debbugs.gnu.org
Received: via spool by 43086-submit <at> debbugs.gnu.org id=B43086.172584176023841
          (code B ref 43086); Mon, 09 Sep 2024 00:30:02 +0000
Received: (at 43086) by debbugs.gnu.org; 9 Sep 2024 00:29:20 +0000
Received: from localhost ([127.0.0.1]:60310 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1snSHQ-0006CT-2n
	for submit <at> debbugs.gnu.org; Sun, 08 Sep 2024 20:29:20 -0400
Received: from forward502a.mail.yandex.net ([178.154.239.82]:33012)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dgutov@HIDDEN>) id 1snSHN-0006CJ-Mk
 for 43086 <at> debbugs.gnu.org; Sun, 08 Sep 2024 20:29:18 -0400
Received: from mail-nwsmtp-smtp-production-main-51.vla.yp-c.yandex.net
 (mail-nwsmtp-smtp-production-main-51.vla.yp-c.yandex.net
 [IPv6:2a02:6b8:c0f:4c80:0:640:a0f:0])
 by forward502a.mail.yandex.net (Yandex) with ESMTPS id 814D060DBC;
 Mon,  9 Sep 2024 03:29:12 +0300 (MSK)
Received: by mail-nwsmtp-smtp-production-main-51.vla.yp-c.yandex.net
 (smtp/Yandex) with ESMTPSA id 8TUJrQuGdW20-9YAKQKNF; 
 Mon, 09 Sep 2024 03:29:11 +0300
X-Yandex-Fwd: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail;
 t=1725841751; bh=A/9vY4ZNqVRAiV1S+IckVmeUKTsiqdbl5mYe/8by/Cs=;
 h=In-Reply-To:From:Subject:Message-ID:Cc:References:Date:To;
 b=Tt2DkuivyF8TlwANKli+l9mRNoxT0pCP7Br850D1q9m0neb7gNTE7E+t5qQvORaTN
 s9WT3Ocy+NjUjFUOStewYpq/MV/Jo9QcokJb7DVjGNGqCw9SZKtVk+0AvaIEo8mW/c
 sSQRGLJyGa+u/UKxk9skp1lebP1hhmMUJojbDM84=
Authentication-Results: mail-nwsmtp-smtp-production-main-51.vla.yp-c.yandex.net;
 dkim=pass header.i=@yandex.ru
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
 [10.202.2.46])
 by mailfauth.phl.internal (Postfix) with ESMTP id 93F141200043;
 Sun,  8 Sep 2024 20:29:08 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-06.internal (MEProxy); Sun, 08 Sep 2024 20:29:08 -0400
X-ME-Sender: <xms:VEHeZjJSHaMDw37YoHmysCJsdwizl24AKy8BTp6Ag9j1e7Mq8ujbfg>
 <xme:VEHeZnIHYzVIMrv1VEhexDsEN20ciHP7L0CKAiGbigtxiGgV9zvBmi-dA8ZCP3Z6o
 mKZpwZmFFBa3VEhdqQ>
X-ME-Received: <xmr:VEHeZrvvUmQ7VoWccJ2vQa-E_6-ovXuIDNsfFXEZtf_JcaAL3bbU3_WmqOTGRHUSs8z7>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudeiiedgfeejucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
 rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
 htshculddquddttddmnegovehorghsthgrlhdqrfegfedtqdeigeculdeftddtmdenucfj
 ughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihhtrh
 ihucfiuhhtohhvuceoughguhhtohhvseihrghnuggvgidrrhhuqeenucggtffrrghtthgv
 rhhnpeeihfejueevteffffdvfeetffffkefhuedujeeiheehiedulefghefgffefudffud
 enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegughhu
 thhovhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudeffeefleelheehvd
 dqvdelgeejjeejjeeiqdgughhuthhovheppeihrghnuggvgidrrhhusehfrghsthhmrghi
 lhdrtghomhdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpth
 htohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtohepphhhihhlihhpkhesphhoshht
 vghordhnvghtpdhrtghpthhtohepgeeftdekieesuggvsggsuhhgshdrghhnuhdrohhrgh
X-ME-Proxy: <xmx:VEHeZsaA-ankjichU8CtAtqVy9ec3cq9ZEumqb1Th69GRRNMMf8ESQ>
 <xmx:VEHeZqZ8uS-tml_utHFFfYgcAOWcgyIZa7WbBNFV3mkKcZ7_rUNTIA>
 <xmx:VEHeZgDT5VUkXUZnpbNIXe47ZbtN66dwdis3bv_iPAxrJLhs7qz5PQ>
 <xmx:VEHeZoZoCgUnAWteelZHSbWMEYa8elPO0cNJ_NMQSkD9PriIy2JxAQ>
 <xmx:VEHeZuqxjxeIA2k8uuMzRIzY58Yo6YD6Rs6Javr-RXcWFmZrH2mheLwb>
Feedback-ID: ib1d9465d:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 8 Sep 2024 20:29:07 -0400 (EDT)
Message-ID: <fdf1ced4-cf5a-464d-ba46-648841590133@HIDDEN>
Date: Mon, 9 Sep 2024 03:29:05 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <87k0xjue75.fsf@HIDDEN>
 <cfd9096b-6787-236e-7780-df2aa63a94d3@HIDDEN> <87zfoog084.fsf@HIDDEN>
 <ef6452be-d2d2-40f9-9302-d3c7c245f3ce@HIDDEN> <86v7z8yojd.fsf@HIDDEN>
Content-Language: en-US
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <86v7z8yojd.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.0 (/)
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 07/09/2024 09:18, Eli Zaretskii wrote:

>> Maybe just like this? This makes Xref identifier completion not query
>> for TAGS unless already loaded. In many cases that would be TRT,
>> although `C-u M-.` seems to regress (seems like we *would* want to query
>> eagerly there).
> 
> I don't understand why the obvious way of asking the user whether they
> would like to generate the tags table is not the solution here.  What
> did I miss?

I don't know if it's obvious, given that the optimal scenario at the 
beginning of the report describes

   ... allow the backend to never query a TAGS file

Adding a query to avoid querying might not be ideal. And if we did 
query, that would raise a question of where to store the answer (should 
it be global, or per-project, or temporary somehow?).

As it is, we already have a hint of the user preference from the fact 
that they have visited a TAGS file already (or not), or enabled 
etags-regen-mode (or not). It's not ironclad, but we could rely on these 
indicators to decide.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43086: [PATCH] Allow tags backend to not query for TAGS file
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 09 Sep 2024 11:55:02 +0000
Resent-Message-ID: <handler.43086.B43086.17258828632120 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43086
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: philipk@HIDDEN, 43086 <at> debbugs.gnu.org
Received: via spool by 43086-submit <at> debbugs.gnu.org id=B43086.17258828632120
          (code B ref 43086); Mon, 09 Sep 2024 11:55:02 +0000
Received: (at 43086) by debbugs.gnu.org; 9 Sep 2024 11:54:23 +0000
Received: from localhost ([127.0.0.1]:60810 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sncyM-0000Y7-SX
	for submit <at> debbugs.gnu.org; Mon, 09 Sep 2024 07:54:23 -0400
Received: from eggs.gnu.org ([209.51.188.92]:32874)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sncyJ-0000Xp-SK
 for 43086 <at> debbugs.gnu.org; Mon, 09 Sep 2024 07:54:20 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1sncyA-0002xp-95; Mon, 09 Sep 2024 07:54:10 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=mPZOe7sGHZGcyfx2fSKg1xcFhRwWdnsZEmj5ZwD/eIo=; b=Aifoc7CtDEXL
 91Ai4Nmw64ds5JHcwujiVjAlCj70CO//Khv61o1O+2s2gsk7pNCtsyf+gi94PQ75GMaptAKsfJXa9
 vX5d6P8mPKMVZvezYmh9tJKdDnXGxsIfzKvm5Yspnorzhe1wYqAdD6OmooEH19b5NqPjyOyFmkI67
 mR9W7P2uonRkoNk8xTmGg3NCQHmxTMOyBzVYzW8oGRQtiSKeAt8JWKPtfefaKsf5zFSDuiW3QBV6f
 G+k0H+aUFBbm7yZ+4ndDsqyGawWFxyaozyoJvxJpfDnrHLOTn4fjfi2205zSEZaEaVfx95qWc0g05
 K2PoAEtY9EeXmPGYaVE0Dg==;
Date: Mon, 09 Sep 2024 14:54:05 +0300
Message-Id: <864j6pvy8y.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <fdf1ced4-cf5a-464d-ba46-648841590133@HIDDEN> (message from
 Dmitry Gutov on Mon, 9 Sep 2024 03:29:05 +0300)
References: <87k0xjue75.fsf@HIDDEN>
 <cfd9096b-6787-236e-7780-df2aa63a94d3@HIDDEN> <87zfoog084.fsf@HIDDEN>
 <ef6452be-d2d2-40f9-9302-d3c7c245f3ce@HIDDEN> <86v7z8yojd.fsf@HIDDEN>
 <fdf1ced4-cf5a-464d-ba46-648841590133@HIDDEN>
X-Spam-Score: -2.3 (--)
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 (---)

> Date: Mon, 9 Sep 2024 03:29:05 +0300
> Cc: philipk@HIDDEN, 43086 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov@HIDDEN>
> 
> On 07/09/2024 09:18, Eli Zaretskii wrote:
> 
> >> Maybe just like this? This makes Xref identifier completion not query
> >> for TAGS unless already loaded. In many cases that would be TRT,
> >> although `C-u M-.` seems to regress (seems like we *would* want to query
> >> eagerly there).
> > 
> > I don't understand why the obvious way of asking the user whether they
> > would like to generate the tags table is not the solution here.  What
> > did I miss?
> 
> I don't know if it's obvious, given that the optimal scenario at the 
> beginning of the report describes
> 
>    ... allow the backend to never query a TAGS file

But what do you expect from a backend that depends on TAGS to do when
TAGS is not there?  You yourself just noticed the regression.  Why
would we want that?

AFAIU, the problem here is that the backend can avoid querying when
the TAGS file exists.  But what do you expect it to do when it does
_not_ exist?  We have the regeneration feature now, so I suggested to
ask the user whether to regenerate the file, after which it could be
read without any further prompts.

IOW, the query I suggested was not the query the OP suggested to
avoid, it's a different query due to different kind of trouble.

> Adding a query to avoid querying might not be ideal. And if we did 
> query, that would raise a question of where to store the answer (should 
> it be global, or per-project, or temporary somehow?).

Sorry, you lost me here.

> As it is, we already have a hint of the user preference from the fact 
> that they have visited a TAGS file already (or not), or enabled 
> etags-regen-mode (or not). It's not ironclad, but we could rely on these 
> indicators to decide.

Then regenerate TAGS without asking, if you think it's reasonable.
But letting the backend continue without TAGS is not a reasonable
solution, IMO.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43086: [PATCH] Allow tags backend to not query for TAGS file
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 09 Sep 2024 23:34:01 +0000
Resent-Message-ID: <handler.43086.B43086.172592478413924 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43086
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eli Zaretskii <eliz@HIDDEN>
Cc: philipk@HIDDEN, 43086 <at> debbugs.gnu.org
Received: via spool by 43086-submit <at> debbugs.gnu.org id=B43086.172592478413924
          (code B ref 43086); Mon, 09 Sep 2024 23:34:01 +0000
Received: (at 43086) by debbugs.gnu.org; 9 Sep 2024 23:33:04 +0000
Received: from localhost ([127.0.0.1]:34366 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1snnsW-0003cU-2f
	for submit <at> debbugs.gnu.org; Mon, 09 Sep 2024 19:33:04 -0400
Received: from forward500b.mail.yandex.net ([178.154.239.144]:47594)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dgutov@HIDDEN>) id 1snnsS-0003c2-5h
 for 43086 <at> debbugs.gnu.org; Mon, 09 Sep 2024 19:33:02 -0400
Received: from mail-nwsmtp-smtp-production-main-31.sas.yp-c.yandex.net
 (mail-nwsmtp-smtp-production-main-31.sas.yp-c.yandex.net
 [IPv6:2a02:6b8:c08:de2c:0:640:e39b:0])
 by forward500b.mail.yandex.net (Yandex) with ESMTPS id 6776360DCC;
 Tue, 10 Sep 2024 02:32:53 +0300 (MSK)
Received: by mail-nwsmtp-smtp-production-main-31.sas.yp-c.yandex.net
 (smtp/Yandex) with ESMTPSA id oWrhWi0s98c0-WEKARMVq; 
 Tue, 10 Sep 2024 02:32:52 +0300
X-Yandex-Fwd: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail;
 t=1725924772; bh=Hr/rV3iVAJLWUpSu9A+Olb3u+YbOh30I8u8yfD3mXiU=;
 h=In-Reply-To:From:Subject:Message-ID:Cc:References:Date:To;
 b=bjEc3mX/cifzz+ykU7wdWp2MnJMiL/Iqbg1+UYSxweNnH6rZ4E5cJF6qLyg4KQrkc
 Dszm84vet97B4D6gX8uIOsEvLn5GvapQ4zgIuPdiKICfHIM4XRDScGu0xXwHBjkLBr
 N9Dpyl5cZXVOIItrbyDQxwrHAExMH1AacaEwlcDY=
Authentication-Results: mail-nwsmtp-smtp-production-main-31.sas.yp-c.yandex.net;
 dkim=pass header.i=@yandex.ru
Received: from phl-compute-07.internal (phl-compute-07.phl.internal
 [10.202.2.47])
 by mailfauth.phl.internal (Postfix) with ESMTP id 8C7E71200078;
 Mon,  9 Sep 2024 19:32:49 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-07.internal (MEProxy); Mon, 09 Sep 2024 19:32:50 -0400
X-ME-Sender: <xms:oYXfZuSTloXu13iCJYUNwPmIDIuTOQYHiglDu5xtLR1qGq8lRUgRWA>
 <xme:oYXfZjzsIYCjmSQ6O0e6chgi46_Thvzj63Gp5DSlcBPJqnAZUQtZssleyM9ZAV2BB
 ujU5HKPsyK9c3ZB_W4>
X-ME-Received: <xmr:oYXfZr3VX8--LkqPFSnCqloZ9DRaisSAECMopXxufITGLsxRr81yWtxU_8fdqvzDEOga>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudeikedgvdehucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
 rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
 htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdej
 necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegughhuthhovheshigrnhguvgigrd
 hruheqnecuggftrfgrthhtvghrnhepiefhjeeuveetffffvdefteffffekhfeuudejieeh
 heeiudelgfehgffffeduffdunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe
 hmrghilhhfrhhomhepughguhhtohhvodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhi
 thihqddufeeffeelleehhedvqddvleegjeejjeejiedqughguhhtohhvpeephigrnhguvg
 igrdhruhesfhgrshhtmhgrihhlrdgtohhmpdhnsggprhgtphhtthhopeefpdhmohguvgep
 shhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhope
 hphhhilhhiphhksehpohhsthgvohdrnhgvthdprhgtphhtthhopeegfedtkeeiseguvggs
 sghughhsrdhgnhhurdhorhhg
X-ME-Proxy: <xmx:oYXfZqA79ZrsM3wIZD_AV4rw9uPq7OGkzl1Or2cx06CcjpWMNuTskg>
 <xmx:oYXfZnjnv0FuCfKKPOH1Xe8Hl4GpZsQQAeWEGhHLL5vUEprKHfOeEA>
 <xmx:oYXfZmr6MVz5_E8GLgAVaD8fRXlGAe4pu3MuWCGVRgLrd21p84PJlA>
 <xmx:oYXfZqhsmGDXD-OZFQN9ADPc7y5mrtM6wReOfgia7eva6r7-IpTaXw>
 <xmx:oYXfZmQAFvZIVQ9bV88L1J2sraHUDhJrVhE5Ow56dT3cZ9cB8D2uCq0m>
Feedback-ID: ib1d9465d:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 9 Sep 2024 19:32:48 -0400 (EDT)
Message-ID: <7a242101-0bbb-43f1-846f-9d2a8f9a3990@HIDDEN>
Date: Tue, 10 Sep 2024 02:32:46 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <87k0xjue75.fsf@HIDDEN>
 <cfd9096b-6787-236e-7780-df2aa63a94d3@HIDDEN> <87zfoog084.fsf@HIDDEN>
 <ef6452be-d2d2-40f9-9302-d3c7c245f3ce@HIDDEN> <86v7z8yojd.fsf@HIDDEN>
 <fdf1ced4-cf5a-464d-ba46-648841590133@HIDDEN> <864j6pvy8y.fsf@HIDDEN>
Content-Language: en-US
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <864j6pvy8y.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.0 (/)
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 09/09/2024 14:54, Eli Zaretskii wrote:
>> Date: Mon, 9 Sep 2024 03:29:05 +0300
>> Cc: philipk@HIDDEN, 43086 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov@HIDDEN>
>>
>> On 07/09/2024 09:18, Eli Zaretskii wrote:
>>
>>>> Maybe just like this? This makes Xref identifier completion not query
>>>> for TAGS unless already loaded. In many cases that would be TRT,
>>>> although `C-u M-.` seems to regress (seems like we *would* want to query
>>>> eagerly there).
>>>
>>> I don't understand why the obvious way of asking the user whether they
>>> would like to generate the tags table is not the solution here.  What
>>> did I miss?
>>
>> I don't know if it's obvious, given that the optimal scenario at the
>> beginning of the report describes
>>
>>     ... allow the backend to never query a TAGS file
> 
> But what do you expect from a backend that depends on TAGS to do when
> TAGS is not there?  You yourself just noticed the regression.  Why
> would we want that?

I'm thinking of the xref-find-references case - where the scanner 
doesn't depend on the tags table being available. Just the identifier 
completion step.

Perhaps Philip had other some situations in mind, too.

> AFAIU, the problem here is that the backend can avoid querying when
> the TAGS file exists.  But what do you expect it to do when it does
> _not_ exist? > We have the regeneration feature now, so I suggested to
> ask the user whether to regenerate the file, after which it could be
> read without any further prompts.

We have an existing way to enable etags-regen-mode. And it's a global 
mode, so it's not just an issue of using it that one time - the naive 
solution will make stay on until the end of the session.

Also, if the tags file is not loaded, we're not quite sure whether the 
user wants an auto-generated file, or an existing one.

>> As it is, we already have a hint of the user preference from the fact
>> that they have visited a TAGS file already (or not), or enabled
>> etags-regen-mode (or not). It's not ironclad, but we could rely on these
>> indicators to decide.
> 
> Then regenerate TAGS without asking, if you think it's reasonable.
> But letting the backend continue without TAGS is not a reasonable
> solution, IMO.

How do you feel about etags-regen-mode being on by default in some next 
Emacs release? It shouldn't conflict with the manual invocations of 'M-x 
visit-tags-file' - and of course if any cases come up we'll work on 
fixing those.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43086: [PATCH] Allow tags backend to not query for TAGS file
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 10 Sep 2024 11:43:01 +0000
Resent-Message-ID: <handler.43086.B43086.172596853024860 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43086
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: philipk@HIDDEN, 43086 <at> debbugs.gnu.org
Received: via spool by 43086-submit <at> debbugs.gnu.org id=B43086.172596853024860
          (code B ref 43086); Tue, 10 Sep 2024 11:43:01 +0000
Received: (at 43086) by debbugs.gnu.org; 10 Sep 2024 11:42:10 +0000
Received: from localhost ([127.0.0.1]:34956 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1snzG5-0006St-K4
	for submit <at> debbugs.gnu.org; Tue, 10 Sep 2024 07:42:10 -0400
Received: from eggs.gnu.org ([209.51.188.92]:33978)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1snzG3-0006Sf-Vh
 for 43086 <at> debbugs.gnu.org; Tue, 10 Sep 2024 07:42:08 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1snzFs-0004zD-GT; Tue, 10 Sep 2024 07:41:56 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=gqS5PPsVha3GGsAENglHN84uhIunYNTx/Gdg2nrVOYs=; b=g10tynPbVbht
 nAIpL4MAFBrahurQb1wMFhAlv7cGOak+0802ydgcZnq4yxlA6U6dakUfQdeq0Rgg024GH7IF3DRb4
 a3nFt8ABNyEjD8EQDB0IEr4rqKci+YkuJYmM/cl8dS82HXM0I60Y/xyKjv4AM1NWkFamcgj4C5WNg
 KSSd7vyygDM+IY4UxH4s0/YSFjDaWy4WLnF/4Cl0PX44HaWvhQUXZRlrSFSlRGa5vCPiT8fWc/mrP
 DkwT3uJDp+DirHqlZ0AEFJdFO8Ck7NxzR4zU+WoOklCmtPQLzDKJYdx+xOneT6SE05PDOgdF4F/Z0
 QvwjpI7Ju48UrnTBe1EeHA==;
Date: Tue, 10 Sep 2024 14:41:43 +0300
Message-Id: <86cylbviq0.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <7a242101-0bbb-43f1-846f-9d2a8f9a3990@HIDDEN> (message from
 Dmitry Gutov on Tue, 10 Sep 2024 02:32:46 +0300)
References: <87k0xjue75.fsf@HIDDEN>
 <cfd9096b-6787-236e-7780-df2aa63a94d3@HIDDEN> <87zfoog084.fsf@HIDDEN>
 <ef6452be-d2d2-40f9-9302-d3c7c245f3ce@HIDDEN> <86v7z8yojd.fsf@HIDDEN>
 <fdf1ced4-cf5a-464d-ba46-648841590133@HIDDEN> <864j6pvy8y.fsf@HIDDEN>
 <7a242101-0bbb-43f1-846f-9d2a8f9a3990@HIDDEN>
X-Spam-Score: -2.3 (--)
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 (---)

> Date: Tue, 10 Sep 2024 02:32:46 +0300
> Cc: philipk@HIDDEN, 43086 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov@HIDDEN>
> 
> >>> I don't understand why the obvious way of asking the user whether they
> >>> would like to generate the tags table is not the solution here.  What
> >>> did I miss?
> >>
> >> I don't know if it's obvious, given that the optimal scenario at the
> >> beginning of the report describes
> >>
> >>     ... allow the backend to never query a TAGS file
> > 
> > But what do you expect from a backend that depends on TAGS to do when
> > TAGS is not there?  You yourself just noticed the regression.  Why
> > would we want that?
> 
> I'm thinking of the xref-find-references case - where the scanner 
> doesn't depend on the tags table being available. Just the identifier 
> completion step.

Completion is also important, IMO.

> > AFAIU, the problem here is that the backend can avoid querying when
> > the TAGS file exists.  But what do you expect it to do when it does
> > _not_ exist? > We have the regeneration feature now, so I suggested to
> > ask the user whether to regenerate the file, after which it could be
> > read without any further prompts.
> 
> We have an existing way to enable etags-regen-mode. And it's a global 
> mode, so it's not just an issue of using it that one time - the naive 
> solution will make stay on until the end of the session.

We could in this particular case enable it once, then disable it after
regenerating TAGS.

> Also, if the tags file is not loaded, we're not quite sure whether the 
> user wants an auto-generated file, or an existing one.

The query should allow the user to tell us his/her preference, no?

> >> As it is, we already have a hint of the user preference from the fact
> >> that they have visited a TAGS file already (or not), or enabled
> >> etags-regen-mode (or not). It's not ironclad, but we could rely on these
> >> indicators to decide.
> > 
> > Then regenerate TAGS without asking, if you think it's reasonable.
> > But letting the backend continue without TAGS is not a reasonable
> > solution, IMO.
> 
> How do you feel about etags-regen-mode being on by default in some next 
> Emacs release? It shouldn't conflict with the manual invocations of 'M-x 
> visit-tags-file' - and of course if any cases come up we'll work on 
> fixing those.

As long as there's a way of turning it off, I don't think I will mind
too much.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43086: [PATCH] Allow tags backend to not query for TAGS file
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 10 Sep 2024 12:46:01 +0000
Resent-Message-ID: <handler.43086.B43086.17259723214916 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43086
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: dgutov@HIDDEN
Cc: philipk@HIDDEN, 43086 <at> debbugs.gnu.org
Received: via spool by 43086-submit <at> debbugs.gnu.org id=B43086.17259723214916
          (code B ref 43086); Tue, 10 Sep 2024 12:46:01 +0000
Received: (at 43086) by debbugs.gnu.org; 10 Sep 2024 12:45:21 +0000
Received: from localhost ([127.0.0.1]:35025 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1so0FE-0001HE-L7
	for submit <at> debbugs.gnu.org; Tue, 10 Sep 2024 08:45:20 -0400
Received: from eggs.gnu.org ([209.51.188.92]:59708)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1so0FC-0001E1-Ge
 for 43086 <at> debbugs.gnu.org; Tue, 10 Sep 2024 08:45:19 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1so0F0-0005u1-PO; Tue, 10 Sep 2024 08:45:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=neMQuaNPAgqufgWVvuyGg8uwgsFygcJYLn3LxUqz/9E=; b=Ygk61gkRyTcj
 //hC+lomjOz8VVHy79lXHJTf9Noqy9EldIVZPiTnRgZ1fZxD8SIdx6ufL1f/Rhl0c1CbykSDxF30Y
 kEDrfHXsp+eBM8S7rypoFPqSly/WUILKu4q3Ms5YzqHkJKyMMQweqOrNMa4xn2xtYMIUmZPWg4CuF
 Yq262cCniK6xCecKtjvcFLpVRUvnDRLaA3Jif8a0Tv29QkTI7xUl+fe2rTaVffy33igatJg6R6bC7
 JyQq2mTOK0Z8sgQJuzi3F67IOU26O2KaqAFR3RSpFS0SVGsveknSk/8HPhc34MUMjUlj4SBJYMz9y
 mQFdmZq8dhh802VPlcZd6w==;
Date: Tue, 10 Sep 2024 15:45:05 +0300
Message-Id: <8634m7vfse.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <86cylbviq0.fsf@HIDDEN> (message from Eli Zaretskii on Tue, 10
 Sep 2024 14:41:43 +0300)
References: <87k0xjue75.fsf@HIDDEN>
 <cfd9096b-6787-236e-7780-df2aa63a94d3@HIDDEN> <87zfoog084.fsf@HIDDEN>
 <ef6452be-d2d2-40f9-9302-d3c7c245f3ce@HIDDEN> <86v7z8yojd.fsf@HIDDEN>
 <fdf1ced4-cf5a-464d-ba46-648841590133@HIDDEN> <864j6pvy8y.fsf@HIDDEN>
 <7a242101-0bbb-43f1-846f-9d2a8f9a3990@HIDDEN> <86cylbviq0.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
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 (---)

> Cc: philipk@HIDDEN, 43086 <at> debbugs.gnu.org
> Date: Tue, 10 Sep 2024 14:41:43 +0300
> From: Eli Zaretskii <eliz@HIDDEN>
> 
> > How do you feel about etags-regen-mode being on by default in some next 
> > Emacs release? It shouldn't conflict with the manual invocations of 'M-x 
> > visit-tags-file' - and of course if any cases come up we'll work on 
> > fixing those.
> 
> As long as there's a way of turning it off, I don't think I will mind
> too much.

Come to think about this: this mode runs 'etags' without any special
switches, right?  Then what will turning this mode ON do in the Emacs
repository, where our 'etags' command is very heavily customized (see
src/Makefile.in)?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43086: [PATCH] Allow tags backend to not query for TAGS file
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 10 Sep 2024 13:32:02 +0000
Resent-Message-ID: <handler.43086.B43086.172597506414769 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43086
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eli Zaretskii <eliz@HIDDEN>
Cc: philipk@HIDDEN, 43086 <at> debbugs.gnu.org
Received: via spool by 43086-submit <at> debbugs.gnu.org id=B43086.172597506414769
          (code B ref 43086); Tue, 10 Sep 2024 13:32:02 +0000
Received: (at 43086) by debbugs.gnu.org; 10 Sep 2024 13:31:04 +0000
Received: from localhost ([127.0.0.1]:35078 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1so0xU-0003q9-14
	for submit <at> debbugs.gnu.org; Tue, 10 Sep 2024 09:31:04 -0400
Received: from forward501d.mail.yandex.net ([178.154.239.209]:44396)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dgutov@HIDDEN>) id 1so0xS-0003pt-7o
 for 43086 <at> debbugs.gnu.org; Tue, 10 Sep 2024 09:31:03 -0400
Received: from mail-nwsmtp-smtp-production-main-84.klg.yp-c.yandex.net
 (mail-nwsmtp-smtp-production-main-84.klg.yp-c.yandex.net
 [IPv6:2a02:6b8:c42:3ca5:0:640:b181:0])
 by forward501d.mail.yandex.net (Yandex) with ESMTPS id 1F0E961386;
 Tue, 10 Sep 2024 16:30:25 +0300 (MSK)
Received: by mail-nwsmtp-smtp-production-main-84.klg.yp-c.yandex.net
 (smtp/Yandex) with ESMTPSA id LUiLYWAoFKo0-WSizmVgc; 
 Tue, 10 Sep 2024 16:30:24 +0300
X-Yandex-Fwd: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail;
 t=1725975024; bh=jhVlksp2j1s5eg2Zc4XK/OSlM3JSdyfdF0jhht1IG6c=;
 h=In-Reply-To:From:Subject:Message-ID:Cc:References:Date:To;
 b=gqniqLzHMny3vd6OFpfmsvbk97aNTadCDHMSw2kJdjiDFEWlMn0WMSnq6XD0hPFl1
 S4TAew8BNxqbcGMPaXmYvKbmkZjUkA8MlwFP9nqc7C8JNRfryr8BxPmAfR7Gz7pZhC
 nRJW95HSc8CErCzSvLmqTDFeHmgIMD4bh7lKRxVw=
Authentication-Results: mail-nwsmtp-smtp-production-main-84.klg.yp-c.yandex.net;
 dkim=pass header.i=@yandex.ru
Received: from phl-compute-10.internal (phl-compute-10.phl.internal
 [10.202.2.50])
 by mailfauth.phl.internal (Postfix) with ESMTP id F378E120008A;
 Tue, 10 Sep 2024 09:30:20 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-10.internal (MEProxy); Tue, 10 Sep 2024 09:30:20 -0400
X-ME-Sender: <xms:7EngZjsmCYzI1hkk-Ko09E7xXuwVwBizXHJFtP-N473g4LsARvRDTA>
 <xme:7EngZkdlmIgoYPijSvjnzCRL6JzNfoGP7A4cu_VlMjMhPQdM5fjOoHLcW7SITpbKF
 d6m-38UWifa59X6yWc>
X-ME-Received: <xmr:7EngZmxBtfrkQiy6qzVk4oKxcRjDXCDGoiAO7S-cTp52PKb43M6itrsJqnoPRM9ATO-u>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudeiledgheejucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
 rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
 htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdej
 necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegughhuthhovheshigrnhguvgigrd
 hruheqnecuggftrfgrthhtvghrnhepiefhjeeuveetffffvdefteffffekhfeuudejieeh
 heeiudelgfehgffffeduffdunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe
 hmrghilhhfrhhomhepughguhhtohhvodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhi
 thihqddufeeffeelleehhedvqddvleegjeejjeejiedqughguhhtohhvpeephigrnhguvg
 igrdhruhesfhgrshhtmhgrihhlrdgtohhmpdhnsggprhgtphhtthhopeefpdhmohguvgep
 shhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhope
 hphhhilhhiphhksehpohhsthgvohdrnhgvthdprhgtphhtthhopeegfedtkeeiseguvggs
 sghughhsrdhgnhhurdhorhhg
X-ME-Proxy: <xmx:7EngZiNPZ9SPTOwqRK5qpb6RIEyy2vkkqWc6DTzlsRvt2cwOE7bDmw>
 <xmx:7EngZj_oncsoHk1n-_EP5bPCWq26GUk08fUDPz-nnT4Sgv_KIq5Htg>
 <xmx:7EngZiUZ382fPd7kSjLQl9ePDmWkPe3dmRja5MKaXbZnO0UdaTW-jA>
 <xmx:7EngZkeETs_i9oN4D10N7j1itSSyxlNm3ET2_QJfuaAJjkf0hoqUqA>
 <xmx:7EngZhfpalt2d9zm2NGSdER-14fWsEEidDjKWoYZ9v1Kq9SYXs__Gszv>
Feedback-ID: ib1d9465d:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 10 Sep 2024 09:30:19 -0400 (EDT)
Message-ID: <9bf7fe99-fd16-45ed-9215-a617de76777f@HIDDEN>
Date: Tue, 10 Sep 2024 16:30:18 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <87k0xjue75.fsf@HIDDEN>
 <cfd9096b-6787-236e-7780-df2aa63a94d3@HIDDEN> <87zfoog084.fsf@HIDDEN>
 <ef6452be-d2d2-40f9-9302-d3c7c245f3ce@HIDDEN> <86v7z8yojd.fsf@HIDDEN>
 <fdf1ced4-cf5a-464d-ba46-648841590133@HIDDEN> <864j6pvy8y.fsf@HIDDEN>
 <7a242101-0bbb-43f1-846f-9d2a8f9a3990@HIDDEN> <86cylbviq0.fsf@HIDDEN>
Content-Language: en-US
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <86cylbviq0.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.0 (/)
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 10/09/2024 14:41, Eli Zaretskii wrote:

>>> But what do you expect from a backend that depends on TAGS to do when
>>> TAGS is not there?  You yourself just noticed the regression.  Why
>>> would we want that?
>>
>> I'm thinking of the xref-find-references case - where the scanner
>> doesn't depend on the tags table being available. Just the identifier
>> completion step.
> 
> Completion is also important, IMO.

Just not always worth the extra query or wait time.

>> We have an existing way to enable etags-regen-mode. And it's a global
>> mode, so it's not just an issue of using it that one time - the naive
>> solution will make stay on until the end of the session.
> 
> We could in this particular case enable it once, then disable it after
> regenerating TAGS.

I'm not sure I'd want a one-time generation of tags which never gets 
updated afterward. Not for me, nor for an inexperienced user who would 
likely get puzzled at some point about why the index not updating.

>> Also, if the tags file is not loaded, we're not quite sure whether the
>> user wants an auto-generated file, or an existing one.
> 
> The query should allow the user to tell us his/her preference, no?

For that we need to decide on the options and the possible lifetimes of 
the answer in advance. That's all I'm saying: it's not an obvious "just 
ask the user".

>> How do you feel about etags-regen-mode being on by default in some next
>> Emacs release? It shouldn't conflict with the manual invocations of 'M-x
>> visit-tags-file' - and of course if any cases come up we'll work on
>> fixing those.
> 
> As long as there's a way of turning it off, I don't think I will mind
> too much.

Great! As long as nobody objects in the coming days I'll switch the 
default value.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43086: [PATCH] Allow tags backend to not query for TAGS file
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 10 Sep 2024 13:34:01 +0000
Resent-Message-ID: <handler.43086.B43086.172597518615012 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43086
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eli Zaretskii <eliz@HIDDEN>
Cc: philipk@HIDDEN, 43086 <at> debbugs.gnu.org
Received: via spool by 43086-submit <at> debbugs.gnu.org id=B43086.172597518615012
          (code B ref 43086); Tue, 10 Sep 2024 13:34:01 +0000
Received: (at 43086) by debbugs.gnu.org; 10 Sep 2024 13:33:06 +0000
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 1so0zR-0003u3-He
	for submit <at> debbugs.gnu.org; Tue, 10 Sep 2024 09:33:05 -0400
Received: from forward501d.mail.yandex.net ([178.154.239.209]:52546)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dgutov@HIDDEN>) id 1so0zO-0003ts-OF
 for 43086 <at> debbugs.gnu.org; Tue, 10 Sep 2024 09:33:04 -0400
Received: from mail-nwsmtp-smtp-production-main-45.klg.yp-c.yandex.net
 (mail-nwsmtp-smtp-production-main-45.klg.yp-c.yandex.net
 [IPv6:2a02:6b8:c42:70a1:0:640:6c31:0])
 by forward501d.mail.yandex.net (Yandex) with ESMTPS id 1B00C61386;
 Tue, 10 Sep 2024 16:32:27 +0300 (MSK)
Received: by mail-nwsmtp-smtp-production-main-45.klg.yp-c.yandex.net
 (smtp/Yandex) with ESMTPSA id OWigtr8Z3mI0-1HqGN2bB; 
 Tue, 10 Sep 2024 16:32:26 +0300
X-Yandex-Fwd: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail;
 t=1725975146; bh=fMXZVKDrFdR7DcShF1GjhkCTgh00HjpHQo6IT5PKk/s=;
 h=In-Reply-To:From:Subject:Message-ID:Cc:References:Date:To;
 b=BtG4s3vQaOWTrHJkawo7t+tdbCQuc+DsGsl4a/s9gVnsRANrBOI6o6W15EtXxO+Bs
 R9UPwma+UxcAPNZlE1ubTfkUHE12dMdJE8zmCCOdmBBK1qr7Jx1J8kwWkW/Fe8rdyf
 xxvKX6VW624KaQmKRnv9bGvrBiRt1O40JMlXSs+Y=
Authentication-Results: mail-nwsmtp-smtp-production-main-45.klg.yp-c.yandex.net;
 dkim=pass header.i=@yandex.ru
Received: from phl-compute-12.internal (phl-compute-12.phl.internal
 [10.202.2.52])
 by mailfauth.phl.internal (Postfix) with ESMTP id 2A2AF1200068;
 Tue, 10 Sep 2024 09:32:24 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-12.internal (MEProxy); Tue, 10 Sep 2024 09:32:24 -0400
X-ME-Sender: <xms:aErgZnyq64ipJIKIJWBajT2km8HCDw4CFN_DynUnAKPdCxsaKwxbKg>
 <xme:aErgZvQayQESreEpXOdLF9LliyiX9m7SD1407iLUNHlf9w1ToFoIEHs8F66iUzWTt
 j1vUe610_UExvCMASY>
X-ME-Received: <xmr:aErgZhUKKNl8UVIf-rnSGauPOTiz717kh3EQ1khX_oNMYH4fwvb8YzfJ6j1uLTPbYGqu>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudeiledgheejucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
 rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
 htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdej
 necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegughhuthhovheshigrnhguvgigrd
 hruheqnecuggftrfgrthhtvghrnhepiefhjeeuveetffffvdefteffffekhfeuudejieeh
 heeiudelgfehgffffeduffdunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe
 hmrghilhhfrhhomhepughguhhtohhvodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhi
 thihqddufeeffeelleehhedvqddvleegjeejjeejiedqughguhhtohhvpeephigrnhguvg
 igrdhruhesfhgrshhtmhgrihhlrdgtohhmpdhnsggprhgtphhtthhopeefpdhmohguvgep
 shhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhope
 hphhhilhhiphhksehpohhsthgvohdrnhgvthdprhgtphhtthhopeegfedtkeeiseguvggs
 sghughhsrdhgnhhurdhorhhg
X-ME-Proxy: <xmx:aErgZhiVWjUaObuRFkWi7K0kRlBB40DRZLa5XwLLF74I6fzqOVPn9A>
 <xmx:aErgZpDP6JfGq5ckZotY6VgmZe_qZIQrgRjtUcullA1FZsjijfxwrQ>
 <xmx:aErgZqJcQpKmzrx-USUN96kFMPIP8S9AD8lL7arYGhhQn1q4n3oo6w>
 <xmx:aErgZoCOcDlcHevnLCfLJ-kJEOK1o5R3oi_GdwAYGvilyjj_WXW_Sg>
 <xmx:aErgZlx5pPvGRsnG54GM2t6VvGzkpg1z1NfeLHiV6yDQqEO9_t_Pkj_C>
Feedback-ID: ib1d9465d:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 10 Sep 2024 09:32:22 -0400 (EDT)
Message-ID: <fa491a64-7c69-4875-a9a6-2439925dfdeb@HIDDEN>
Date: Tue, 10 Sep 2024 16:32:21 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <87k0xjue75.fsf@HIDDEN>
 <cfd9096b-6787-236e-7780-df2aa63a94d3@HIDDEN> <87zfoog084.fsf@HIDDEN>
 <ef6452be-d2d2-40f9-9302-d3c7c245f3ce@HIDDEN> <86v7z8yojd.fsf@HIDDEN>
 <fdf1ced4-cf5a-464d-ba46-648841590133@HIDDEN> <864j6pvy8y.fsf@HIDDEN>
 <7a242101-0bbb-43f1-846f-9d2a8f9a3990@HIDDEN> <86cylbviq0.fsf@HIDDEN>
 <8634m7vfse.fsf@HIDDEN>
Content-Language: en-US
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <8634m7vfse.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.0 (/)
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 10/09/2024 15:45, Eli Zaretskii wrote:
>> Cc: philipk@HIDDEN, 43086 <at> debbugs.gnu.org
>> Date: Tue, 10 Sep 2024 14:41:43 +0300
>> From: Eli Zaretskii <eliz@HIDDEN>
>>
>>> How do you feel about etags-regen-mode being on by default in some next
>>> Emacs release? It shouldn't conflict with the manual invocations of 'M-x
>>> visit-tags-file' - and of course if any cases come up we'll work on
>>> fixing those.
>>
>> As long as there's a way of turning it off, I don't think I will mind
>> too much.
> 
> Come to think about this: this mode runs 'etags' without any special
> switches, right?  Then what will turning this mode ON do in the Emacs
> repository, where our 'etags' command is very heavily customized (see
> src/Makefile.in)?

etags-regen-mode doesn't know how to parse Makefile.in, and it doesn't 
seem feasible, so it needs the user to customize 
`etags-regen-regexp-alist` for any special rules.

That's already done in the Emacs repo, see our .dir-locals.el.

Last modified: Sun, 12 Jan 2025 05:45:02 UTC

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