Re: Automatic (e)tags generation and incremental updates

[Eli Zaretskii <eliz@gnu.org>]

> Cc: philipk@posteo.net, tom@tromey.com, john@yates-sheets.org,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 20 Feb 2021 03:35:40 +0200
> 
> 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.

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?

Or what am I missing?

> 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:

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