|
From: | Dmitry Gutov |
Subject: | Re: Automatic (e)tags generation and incremental updates |
Date: | Sat, 20 Feb 2021 23:05:11 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
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 +0200But 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.
[Prev in Thread] | Current Thread | [Next in Thread] |