Re: Setup process for etags-regen-mode (Emacs 30.0.91 feedback)

[Dmitry Gutov <dmitry@gutov.dev>]

Hi!

On 20/09/2024 21:14, Morgan Willcock wrote:
> When testing etags-regen-mode in the Emacs 30 pre-release I've found it
> to be working well for my use-case, but one thing which appears to be
> missing is an easy way for additional completion functions to opt-in to
> the etags-regen-mode setup process.
> 
> Currently the completion functions which get advice added to them (to
> call etags-regen--maybe-generate) are hard coded in the mode definition:
> 
>    (if etags-regen-mode
>          (progn
>            (advice-add 'etags--xref-backend :before
>                        #'etags-regen--maybe-generate )
>            (advice-add 'tags-completion-at-point-function :before
>                        #'etags-regen--maybe-generate))
>        (advice-remove 'etags--xref-backend #'etags-regen--maybe-generate)
>        (advice-remove 'tags-completion-at-point-function #'etags-regen--maybe-generate)
>        (etags-regen--tags-cleanup))
> 
> I was looking for a stable entry point to opt-in to using it, rather
> than having to do something like this:
> 
>    (advice-add 'my-completion-function-which-does-things-with-tags :before
>                #'etags-regen--maybe-generate)
> 
> (Where the "--" in the function name is a sign that I probably shouldn't
> be doing that.)
> 
> I wasn't sure whether it was intentional to hard-code the functions to
> advise while etags-regen-mode was still so new, or whether opting in
> other functions hadn't been considered.

Hadn't been considered yet, but I'm open to the idea. Two basic 
approaches is either through a new custom variable, or by making the 
function "public".

The latter is a bit tricky because then we'd need to document what it 
does - and it basically launches all the work ((re)scanning the table, 
adding the hooks), and that setup might change over time.

> Would it be possible to store the completion functions which will be
> advised as a separate list, so that other packages can add completion
> functions to that list and get the TAGS generation to trigger?  Or is
> this an intentional boundary?

The custom variable approach seems better, but we'll need to test how it 
interacts with being able to switch etags-regen-mode on by default.