[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Automatic (e)tags generation and incremental updates
From: |
Eli Zaretskii |
Subject: |
Re: Automatic (e)tags generation and incremental updates |
Date: |
Sat, 20 Feb 2021 09:30:18 +0200 |
> 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 03:35:40 +0200
>
> 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.
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?
Or what am I missing?
> 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.
Maybe I still don't understand something: how would "compatibility
with 'ctags -e'" be different from what is discussed here, including
this:
> 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?).
The equivalent of --langmap is "-l LANG", I think. (We could also
teach etags to support --langmap directly, patches welcome.)
- Re: Automatic (e)tags generation and incremental updates, Dmitry Gutov, 2021/02/18
- Re: Automatic (e)tags generation and incremental updates, Eli Zaretskii, 2021/02/19
- Re: Automatic (e)tags generation and incremental updates, Dmitry Gutov, 2021/02/19
- Re: Automatic (e)tags generation and incremental updates, Eli Zaretskii, 2021/02/19
- Re: Automatic (e)tags generation and incremental updates, Dmitry Gutov, 2021/02/19
- Re: Automatic (e)tags generation and incremental updates,
Eli Zaretskii <=
- Re: Automatic (e)tags generation and incremental updates, Dmitry Gutov, 2021/02/20
- Re: Automatic (e)tags generation and incremental updates, Eli Zaretskii, 2021/02/20
- Re: Automatic (e)tags generation and incremental updates, Dmitry Gutov, 2021/02/20
- Re: Automatic (e)tags generation and incremental updates, Dmitry Gutov, 2021/02/20
- Re: Automatic (e)tags generation and incremental updates, Eli Zaretskii, 2021/02/21
- Re: Automatic (e)tags generation and incremental updates, Dmitry Gutov, 2021/02/21
- Re: Automatic (e)tags generation and incremental updates, Eli Zaretskii, 2021/02/22
- Re: Automatic (e)tags generation and incremental updates, Dmitry Gutov, 2021/02/22
- Re: Automatic (e)tags generation and incremental updates, Eli Zaretskii, 2021/02/22
- Re: Automatic (e)tags generation and incremental updates, Dmitry Gutov, 2021/02/22