> Date: Tue, 10 Sep 2024 02:32:46 +0300 > Cc: phil...@posteo.net, 43...@debbugs.gnu.org > From: Dmitry Gutov <dgu...@yandex.ru> > > >>> 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.
Completion is also important, IMO. > > 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. We could in this particular case enable it once, then disable it after regenerating TAGS. > 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. The query should allow the user to tell us his/her preference, no? > >> 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. As long as there's a way of turning it off, I don't think I will mind too much.
