From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Philip K." Newsgroups: gmane.emacs.bugs Subject: bug#43086: [PATCH] Allow tags backend to not query for TAGS file Date: Sun, 06 Sep 2020 23:50:54 +0200 Message-ID: <87d02yefr5.fsf@posteo.net> References: <87k0xjue75.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3270"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 43086@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 06 23:52:11 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kF2a2-0000kX-Uy for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 06 Sep 2020 23:52:10 +0200 Original-Received: from localhost ([::1]:56890 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kF2a2-0006q3-1u for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 06 Sep 2020 17:52:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56650) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kF2Zu-0006no-SZ for bug-gnu-emacs@gnu.org; Sun, 06 Sep 2020 17:52:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35744) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kF2Zu-0007Rn-J8 for bug-gnu-emacs@gnu.org; Sun, 06 Sep 2020 17:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kF2Zu-0003kg-Hi for bug-gnu-emacs@gnu.org; Sun, 06 Sep 2020 17:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Philip K." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Sep 2020 21:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43086 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 43086-submit@debbugs.gnu.org id=B43086.159942906314355 (code B ref 43086); Sun, 06 Sep 2020 21:52:02 +0000 Original-Received: (at 43086) by debbugs.gnu.org; 6 Sep 2020 21:51:03 +0000 Original-Received: from localhost ([127.0.0.1]:47290 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kF2Yx-0003jT-Ds for submit@debbugs.gnu.org; Sun, 06 Sep 2020 17:51:03 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:58609) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kF2Yv-0003ir-Rv for 43086@debbugs.gnu.org; Sun, 06 Sep 2020 17:51:02 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 52EBD16005F for <43086@debbugs.gnu.org>; Sun, 6 Sep 2020 23:50:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1599429055; bh=rI9e75aLrSeMl/qDX758PRbiO09uVO+/wp9SzueLifI=; h=From:To:Cc:Subject:Date:From; b=ekiw8IjTaudMSZzRhJQrZX6Bjg6UV5/nIfhhoPq3z7nG/NQfSwr4DkLWYKXjYaIMu Hk2a04dhkXnrAzT9LVoHwea5tqXu0FUlwxXNk4agdEPnR6xdB52EFm3YIJs4fgs4JP SBqvqfTfv5iVoytY9in0EZOhTaEKLfzKx91Wxg4iy6m1wEMWv+6lcGu6Emb5NQNKKY 8aUCP0olBsXRgtb6XaLZLItgBisXV7II1PCC1H7fIYQ0//aSimiBQqksiRFNITbEpG RL+6IKwjE8XVQ5cDD5LtrcBF4X55W/qzWr2nG0YLntiTIdPQPRaXy0Qwt9S09rwR9H lTzLKa8ZGQK3A== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Bl4q24kMBz9rxD; Sun, 6 Sep 2020 23:50:54 +0200 (CEST) In-Reply-To: (message from Dmitry Gutov on Sat, 5 Sep 2020 03:45:17 +0300) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:187387 Archived-At: Dmitry Gutov 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.