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: Fri, 19 Feb 2021 17:44:19 +0200 Message-ID: <834ki82hbh.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8248"; 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 Fri Feb 19 16:46: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 1lD7yw-00021G-S2 for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Feb 2021 16:46:14 +0100 Original-Received: from localhost ([::1]:42838 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lD7yv-0007vq-Nb for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Feb 2021 10:46:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47546) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lD7wu-00068d-0l for emacs-devel@gnu.org; Fri, 19 Feb 2021 10:44:08 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50854) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lD7ws-0001r5-QR; Fri, 19 Feb 2021 10:44:06 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2056 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lD7wq-0005QA-RO; Fri, 19 Feb 2021 10:44:05 -0500 In-Reply-To: <5de633e5-05c3-d965-e6b1-b8bb91a8f11a@yandex.ru> (message from Dmitry Gutov on Fri, 19 Feb 2021 16:35:00 +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:265263 Archived-At: > Cc: philipk@posteo.net, tom@tromey.com, john@yates-sheets.org, > emacs-devel@gnu.org > From: Dmitry Gutov > Date: Fri, 19 Feb 2021 16:35:00 +0200 > > > . this lacks the proper documentation (we should at least say that > > -L is for compatibility with ...) and NEWS item > > Sure. I was hoping you might do that, as someone more familiar with its > documentation, but it doesn't sound too hard. If you need help with this, I can help. > > . it should have a corresponding long-option name, and thus should > > be reflected in longopts[] > > Any suggestions? ctags doesn't have a long variant, just '-L'. > > --list-from-file ? SGTM. > Well, there are several options before me: > > - Only support Emacs's etags. Given the momentum behind the > universal-ctags project and the fact that 'etags' is often an alias to > [an old version of] ctags on users' machines, that might be unfortunate. > In particular from the "working out of the box" perspective. > > - Apply the patch I posted and support only the latest etags, as well as > all known ctags versions. Only to an extent, however: the way > etags-regen-lang-regexp-alist is applied is dependent on the '--regex=' > option syntax, and ctags yet again has a different one (--regex-). > So either this option won't be supported with ctags, or etags will need > another change for compatibility, or... > > - ...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. 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?