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

[Philip K.]

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.

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