bug#67687: Feature request: automatic tags management

[Dmitry Gutov <dmitry@gutov.dev>]

On 31/12/2023 09:07, Eli Zaretskii wrote:
>> Date: Sun, 31 Dec 2023 01:43:25 +0200
>> Cc: 67687@debbugs.gnu.org, eskinjp@gmail.com, stefankangas@gmail.com
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>>>>>> +;;;###autoload
>>>>>> +(put 'etags-regen-file-extensions 'safe-local-variable
>>>>>> +     (lambda (value) (and (listp value) (seq-every-p #'stringp value))))
>>>>>
>>>>> Why not use list-of-strings-p here?
>>>>
>>>> Again, that "core ELPA" consideration. We could deploy this feature to a
>>>> number of released Emacs versions, if we don't introduce such dependencies.
>>>
>>> Isn't this covered by the compat package on ELPA?  If not, I think it
>>> should be.
>>
>> These forms go into generated autoloads file for each installed package
>> (*-autoloads.el). I think compat doesn't make list-of-string-p
>> autoloaded, and autoloads files don't usually have (require ...) forms.
>>
>> So while I haven't really tested this and could be missing something, it
>> seems brittle to rely on 'compat' for this function (if at all possible).
> 
> It is also extremely ugly to have those large functions in a bundled
> package, when we already have list-of-strings-p in Emacs 29.  So how
> about defining list-of-strings-p in etags-regen for older versions,
> and then using it in the safe-local-variable property?

Even that wouldn't work, I think, for the same reason: the autoloads 
file doesn't load the related package eagerly. Though I suppose we could 
force one specific function definition into autoloads.

> Or some other
> solution to make this more elegant.  Wanting to let users use this
> with older Emacsen has its limits, and IMNSHO this one crosses that
> limit.

We already do this in project.el for one variable, too.

If you like, we could simplify the forms further, though, dropping the 
string-match-p checks. Forms for etags-regen-file-extensions and 
etags-regen-ignores would look like the one for 
project-vc-extra-root-markers.

The form for etags-regen-lang-regexp-alist is not a lists-of-string-p to 
begin with, so it will be more complex (it's "alist of lists of strings").