Re: Automatic (e)tags generation and incremental updates

[Dmitry Gutov <dgutov@yandex.ru>]

On 20.02.2021 09:30, Eli Zaretskii wrote:

>>> It sounds like a fully compatible code is not really possible, so some
>>> test to detect which etags/ctags program will run, with the necessary
>>> code tailored to each of them, seems like the best COA in the long
>>> run.  It's a bit more coding, but the differences are fairly minor, so
>>> I don't expect that to be too hard.
>>
>> It's one more source of bugs, because I would personally be using only
>> one of the code paths on the regular basis, and the same might be true
>> for emacs-devel regulars who might try it out.
> 
> But below you propose a compatibility layer anyway, for the regular
> expressions, right?  So the danger of less testing and more bugs still
> exists under that proposal, AFAIU.  And the compatibility code for
> using "-L -" vs just "-" is very simple, so why not put it under the
> same condition as what you plan for the regexp compatibility?

That would work quite differently: etags wouldn't have to launch an 
external executable and somehow guess whether it supports some flags. It 
will just add for support some new (common) ones.

And if etags-regen will exercise just a limited set of them won't result 
in any kind of instability in the package. Or should not, at least.

There is still some risk, of course, but that would stem from possible 
differences in the implementation of said options between etags and ctags.

>> But in the long run, it might be good for us to have a better level of
>> compatibility with 'ctags -e': less user confusion, for one thing. And
>> for best results, I think we should approach that compatibility from our
>> side (if we do at all), rather than wait for them, because older
>> versions of third-party software will be around for a long time, but we
>> can more or less be sure that Emacs comes with the latest version of etags.
> 
> Maybe I still don't understand something: how would "compatibility
> with 'ctags -e'" be different from what is discussed here, including
> this:

Same thing. That's why I'm asking for it, right?

>> FWIW, -L plus a compatibility layer for --regex (translating
>> --regex-lang=abc to --regex={lang}abc) should suffice for etags-regen
>> for the near future.
>>
>> And support for --langmap, maybe (does etags have a counterpart for it
>> at all?).
> 
> The equivalent of --langmap is "-l LANG", I think.  (We could also
> teach etags to support --langmap directly, patches welcome.)

If such patch materializes, any chance we could put it into emacs-27 as 
well?

Then I could use some pointers: for example, which stdlib and/or utility 
functions you would expect one would use to add this feature. Just the 
names could suffice.