Re: Automatic (e)tags generation and incremental updates

[Dmitry Gutov]

On 19.02.2021 10:33, Eli Zaretskii wrote:
> > From: Dmitry Gutov <dgutov@yandex.ru>
> > Cc: philipk@posteo.net, tom@tromey.com, john@yates-sheets.org,
> >   emacs-devel@gnu.org
> > Date: Fri, 19 Feb 2021 01:26:43 +0200
> >
> > On 07.01.2021 17:56, Dmitry Gutov wrote:
> > > - A change to lib-src/etags.c which implements handing of '-L' flag, for
> > > compatibility with ctags.
> >
> > How do you feel about cherry-picking this particular change to the
> > emacs-27 release branch?
>
> I don't mind in general, but:
>
>    . this lacks the proper documentation (we should at least say that
>      -L is for compatibility with ...) and NEWS item

Sure. I was hoping you might do that, as someone more familiar with its 
documentation, but it doesn't sound too hard.

>    . it should have a corresponding long-option name, and thus should
>      be reflected in longopts[]

Any suggestions? ctags doesn't have a long variant, just '-L'.

--list-from-file ?

> > Or if you don't, how do you feel about that code change at all? One
> > alternative for me is to try to support both 'ctags -e' and 'etags',
> > with some ad-hoc version detection, I guess. Then the change won't be
> > needed.
>
> Sorry, I don't think I follow.  Can you elaborate on this?

Well, there are several options before me:

- Only support Emacs's etags. Given the momentum behind the 
universal-ctags project and the fact that 'etags' is often an alias to 
[an old version of] ctags on users' machines, that might be unfortunate. 
In particular from the "working out of the box" perspective.

- Apply the patch I posted and support only the latest etags, as well as 
all known ctags versions. Only to an extent, however: the way 
etags-regen-lang-regexp-alist is applied is dependent on the '--regex=' 
option syntax, and ctags yet again has a different one (--regex-<lang>). 
So either this option won't be supported with ctags, or etags will need 
another change for compatibility, or...

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