bug#43086: [PATCH] Allow tags backend to not query for TAGS file

[Dmitry Gutov]

On 07.09.2020 00:50, Philip K. wrote:
> Dmitry Gutov <dgutov@yandex.ru> 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.

etags-project.diff
Description: Text Data