From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Alfred M. Szmidt" Newsgroups: gmane.emacs.devel Subject: Re: etags name collision. Date: Tue, 12 Apr 2022 13:21:53 -0400 Message-ID: References: <20220411124736.3qijvtearh6wlen7.ref@Ergus> <20220411124736.3qijvtearh6wlen7@Ergus> <83pmln69n0.fsf@gnu.org> <20220411135259.zqrlngj6lmpgbsni@Ergus> <83ilrf6779.fsf@gnu.org> <20220411142519.vnbr63lfpyuqpw2w@Ergus> <20220412104823.xfquehpmoghektkt@Ergus> <20220412164016.y3qbycbbf5gwujuy@Ergus> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31949"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eliz@gnu.org, dgutov@yandex.ru, emacs-devel@gnu.org To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 12 19:22:28 2022 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 1neKDj-0008B2-ED for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Apr 2022 19:22:27 +0200 Original-Received: from localhost ([::1]:37836 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1neKDi-0004UP-77 for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Apr 2022 13:22:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39562) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1neKDB-0003oE-Uk for emacs-devel@gnu.org; Tue, 12 Apr 2022 13:21:53 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44398) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1neKDB-0007Ia-IB; Tue, 12 Apr 2022 13:21:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=yF3jAFW7Vc+l7aM+Tg3cgRcJFrMv3NAuoQ/FpZERZDI=; b=VSskwITiGZQn rBRnP592swJrFp+WghnM4k9lAVhNrNUTLmiQSyWdLt/6Kswm/902ktoC+APfQgvV66/8UZHVLItlV HJYU97fWr0fkJyTovK5EfCTB7fLzo6zHqciNhLQ7EYRGSQ4vTI5N41K1eVNBdi7Av4M0LYv9ic7oK QvJjrANkL9UlwcZFsohnncK+9fMyUy0Zea56Cyrngi0fPlzMZrFpjymjl9I5L5i5SSspJSfwX5fsj Ki0jF1Czn+gnXvEY4OjtwOvkHS+AgQhJNTMPwE3tnVKicMuHeUjogyZ6J3CzgKwy4R2wwTZKPNq5f bHR5a9f3U7TBGq99TqatHg==; Original-Received: from ams by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1neKDB-0007vW-Au; Tue, 12 Apr 2022 13:21:53 -0400 In-Reply-To: <20220412164016.y3qbycbbf5gwujuy@Ergus> (message from Ergus on Tue, 12 Apr 2022 18:40:16 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:288321 Archived-At: > >Not all systems use Exuberant Ctags or Universal Ctags. On the BSDs, > >ctags is compatible with the Emacs ctags output (which is why it > >exists, AFAIR). Exuberant Ctags etc do not work with either vi(1) or > >mg(1) on those systems, and their output is at odds with what is > >standardized by POSIX. > > In what sense it is not standarized by POSIX? > >The output from Exuberant ctags is not what POSIX asks for. Programs >that expect the POSIX format will thus not work, or do funny stuff. Again, I haven't observed that, that's exactly my point, if there is an issue in universal ctags output format it should be reported, but I haven't observed any mismatch. I have observed the case, the POSIX format is stricter, the output from ctags as specified by POSIX is (there are slight variants, but it is always three fields): "%s\t%s\t/%s/\n", , , for example, GNU Emacs ctags outputs: syms_of_cmds cmds.c /^syms_of_cmds (void)$/ where Exuberant (and Universal) ctags outputs: syms_of_cmds cmds.c /^syms_of_cmds (void)$/;" f typeref:typename:void It is fair to fail on not being able to accept the above, or treating the third field as one. And one might also question how to treat a pattern with a trailing double quote. > >So really, you're suggesting to remove a standardized utility and > >replace it with non-standard ones that produce incompatible output > >from what is generally accepted. > > I am suggesting to avoid the forced installation of a utility that we > are not maintaining very well for another very well maintained, with > more languages, support and formats. > >That is changing the point I was making, that Emacs ctags produces the >standard ctags output where Exuberant ctags does not. Universal ctags DOES generate standard ctags format (and some others like etags format); they actually explicitly refer to vi in the man page. No, it does not. See above; from Universal ctags from 2019. Exuberant is not maintained since 2011. People still use software that is older, just that something is "not maintained" (which can mean many things) doesn't mean that it stops being useless. If there is the free and active universal ctags with a big and active team doing that work and supporting many format and languages, then it is pointless to duplicate effort and invest time on that. Don't reinvent the wheel. That is quite a dismissive comment, Emacs ctags existed long before any of those existed (and at that point, we did not have any ctags on GNU) so one might question who is reinventing the wheel here...