Re: Automatic (e)tags generation and incremental updates

[Eli Zaretskii]

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

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

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