|
From: | Dmitry Gutov |
Subject: | Re: Automatic (e)tags generation and incremental updates |
Date: | Sat, 20 Feb 2021 03:35:40 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
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.
Not too serious a problem, but a problem nevertheless. It also requires us to choose some robust check for which version we're working with.
I also don't mind adding -L, but from what you say it will not be a complete solution anyway, so what do we gain?
I don't have a strong preference and can go with either approach.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.
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?).
[Prev in Thread] | Current Thread | [Next in Thread] |