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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 9 Sep 2024 03:29:05 +0300
> Cc: philipk@posteo.net, 43086@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> 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.