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 22:41:24 +0200 Message-ID: <83y2fixyiz.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> <83im6n19it.fsf@gnu.org> <25073978-eb02-4f40-4104-9d18df87def0@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40511"; 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 21:42:37 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 1lDZ5I-000AS5-Sx for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Feb 2021 21:42:36 +0100 Original-Received: from localhost ([::1]:41838 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lDZ5H-0004EB-UF for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Feb 2021 15:42:35 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33948) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lDZ4R-0003YL-DB for emacs-devel@gnu.org; Sat, 20 Feb 2021 15:41:43 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50699) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lDZ4P-0000OJ-Gl; Sat, 20 Feb 2021 15:41:41 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3252 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lDZ4O-0005HM-RC; Sat, 20 Feb 2021 15:41:41 -0500 In-Reply-To: <25073978-eb02-4f40-4104-9d18df87def0@yandex.ru> (message from Dmitry Gutov on Sat, 20 Feb 2021 22:27:50 +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:265354 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 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.