From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Automatic (e)tags generation and incremental updates Date: Sat, 20 Feb 2021 09:30:18 +0200 Message-ID: <83im6n19it.fsf@gnu.org> References: <779a6328-9ca5-202a-25a2-b270c66fe6dd@yandex.ru> <8fc5e96c-ebb8-c668-9b2a-c7c4ee54c0b9@yandex.ru> <83r1mwltob.fsf@gnu.org> <0bee9ab4-46bc-b6fd-97b6-e26cc80f1610@yandex.ru> <731c1b21-b3e9-89fe-3751-9c2a528adfba@yandex.ru> <838s7k4ft8.fsf@gnu.org> <5de633e5-05c3-d965-e6b1-b8bb91a8f11a@yandex.ru> <834ki82hbh.fsf@gnu.org> <67d2bd44-032d-f014-338f-387a07503d9c@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39147"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philipk@posteo.net, tom@tromey.com, emacs-devel@gnu.org, john@yates-sheets.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Feb 20 08:32:14 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lDMkQ-000A7I-Nl for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Feb 2021 08:32:14 +0100 Original-Received: from localhost ([::1]:36652 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lDMkP-0002q0-Mi for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Feb 2021 02:32:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39766) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lDMiq-0002HQ-OG for emacs-devel@gnu.org; Sat, 20 Feb 2021 02:30:37 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40197) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lDMio-0002KG-Kz; Sat, 20 Feb 2021 02:30:34 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4277 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lDMin-0001aS-VB; Sat, 20 Feb 2021 02:30:34 -0500 In-Reply-To: <67d2bd44-032d-f014-338f-387a07503d9c@yandex.ru> (message from Dmitry Gutov on Sat, 20 Feb 2021 03:35:40 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:265292 Archived-At: > Cc: philipk@posteo.net, tom@tromey.com, john@yates-sheets.org, > emacs-devel@gnu.org > From: Dmitry Gutov > 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.)