On 09/09/2024 14:54, Eli Zaretskii wrote:
Date: Mon, 9 Sep 2024 03:29:05 +0300
Cc: phil...@posteo.net, 43...@debbugs.gnu.org
From: Dmitry Gutov <dgu...@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?
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.
