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