Re: Automatic (e)tags generation and incremental updates

[Dmitry Gutov]

On 20.02.2021 22:41, Eli Zaretskii wrote:
> > 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 22:27:50 +0200
> >
> > > 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.
>
> I don't understand: how would you know which variant to use unless you
> probe the program to see which kind of etags/ctags it is?  You said
> the syntax of the --regexp option is different between these two
> programs, so you must use the right syntax that fits the program being
> invoked.  Right?

If etags adds these new flags, I won't have to.

I'll just say that etags-regen depends on Emacs 27.2+. Maybe add an 
etags version check upon mode activation as well.

> > There is still some risk, of course, but that would stem from possible
> > differences in the implementation of said options between etags and ctags.
>
> "Possible" differences?  But we know what the differences are, so we
> know that they exist, not just as a possibility, right?

I meant the new options, so those would be bugs in their implementations 
(in etags or ctags).

> > > 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?
>
> It depends on how complex it will be, and whether and to what extent
> will it affect the existing code.
>
> > 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.
>
> I didn't think about this too much, but strtok sounds like a good
> start.

All right, thank you.