Re: Automatic (e)tags generation and incremental updates

[Dmitry Gutov <dgutov@yandex.ru>]

On 19.02.2021 17:44, Eli Zaretskii wrote:

>> - ...We add a setting for "etags vendor" and two different code paths
>> anyway. In this case the '-L' compatibility will be moot as well, adding
>> this extra flag - or not - can easily depend on the "vendor" option.
> 
> 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.

Not too serious a problem, but a problem nevertheless. It also requires 
us to choose some robust check for which version we're working with.

> I also don't mind adding -L, but from what you say it will not be a
> complete solution anyway, so what do we gain?

I don't have a strong preference and can go with either approach.

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.

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?).