From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.devel Subject: Re: etags name collision. Date: Tue, 12 Apr 2022 19:48:48 +0200 Message-ID: <20220412174848.ftsa5q6sfkilzk6q@Ergus> References: <83pmln69n0.fsf@gnu.org> <20220411135259.zqrlngj6lmpgbsni@Ergus> <83ilrf6779.fsf@gnu.org> <20220411142519.vnbr63lfpyuqpw2w@Ergus> <20220412104823.xfquehpmoghektkt@Ergus> <20220412164016.y3qbycbbf5gwujuy@Ergus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20597"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eliz@gnu.org, dgutov@yandex.ru, emacs-devel@gnu.org To: "Alfred M. Szmidt" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 12 19:51:08 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 1neKfT-0005EU-UV for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Apr 2022 19:51:08 +0200 Original-Received: from localhost ([::1]:53740 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1neKfS-0001By-Ds for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Apr 2022 13:51:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45470) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1neKdV-0000ID-RB for emacs-devel@gnu.org; Tue, 12 Apr 2022 13:49:05 -0400 Original-Received: from sonic312-21.consmr.mail.bf2.yahoo.com ([74.6.128.83]:43702) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1neKdQ-0002lI-CO for emacs-devel@gnu.org; Tue, 12 Apr 2022 13:49:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1649785739; bh=SNV566axcd3+8+0qblRwN/kuxVRf4m+zSIat98UrpyE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=DZJKi3F2xRYB96SKxlWIjLoAeEYKobyqJSIzXkH00Zil76N5phetSd0Wq8xYwxjgv9DnKa/D20roHi4IBK/gNchpIN6x0cIbkSujfkcRHbr3OuAVyTFGBgp8f0MbeS7FPrGs2eBmiejTSNGcivJJLZz361aUO9PZG1zc589VSQRRV1BsSBTSaJ2UmRdg/hHOGAtXEpTQrtHUJZ8/tpwip1YrzT1/Zj3ZrLwTeSFnsL+MOJyCxFpyugWUG/OwevxBLTZgXqS7XeKf4IC5ikXwxVhzPgQSoyD+BeK+EdDxE2yh+Ya02Uqr1mXYBeWQJYQzRzv0qv/JQ7ODnt/3Z3zfrA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649785739; bh=3eb1RXv8+EpMN+CF+dpCpDgfdVLJK+r6ylG/RaExW6e=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=czvEQ7Mjy+RXdI7aRSbPDTBh7Vy8d0GvZjerzhyUe82m2FUFORe0YORbaS8kntJnhcwVrNqVkyN3WNiFBDBTN4K3S+aWszUHAsqtQLcFEuUrbbT5aE6mZWDSGlbjaYW183Pk49JX7cnLmjUsdL0civ9LwTEKQeI+uJ0B/uuSvHNskj3VClhbS15hOGm+GHAF4W2do5pxWFXNsoK2bxypIt/Lf3soJet3kmzgwJVn0DgqSVS6GNbYSEMAFweCkUA1AjpfwKN0Tsx7TraksMd4S8ToSfno7WXGdHTK5kkDDGTS55zo4PjH8/bPHjHRaqZEZ7vlH5gxPyZL7ye7ENpGhA== X-YMail-OSG: pSVK0.IVM1lNh9MYLGbJwFxB8ycl7wSxVQj9r_Sh2Fn1GCpGWsOqIz9dAWWrcSH xihielN6tuk.xIrMhU6ubG9a6sJWbjghH_clC_R8TmNDWOO3JrQh43MpiEINlDyo80ydsI6pWuLP 6ayXwzDK8YWKfqMsjils8CrcFNK2TCpE0mkX6_5d2zsLxAUGtyaA.fb4gMqA2Dk3QZXzTD8aAM1t GDy98KnZYsF0zFtsaq2_84b_a0mqLTO507piIa86oqD8zopcQOESarnDvdDSBhzDlhZR793gISiC 1F.ogEuJEpkH0NI._vCvXP6P3BaDxn3GztiMTfKLzWUDymDG0vmMuVikpYIRkz1wTxiTzScP9m1f H3kL5_2cXrmWzQfOcCBTv9W_oBn3kWuyiaGxF8ixt06WHKz6djluv_nCuIcFUXar6h2o67MS.Msz WMsHB6zNfTSuUsb0YyYHSYhFtq4oi1YL5xLgSoXOxPkonueXXxxWg0Bwxkv4hgtvErg3Wt6SzNTT zP9BQetCN4BWRwvWJONGY_B.spTF3UjWvNUv3dFqdv8Dnkp9RYCQYGoN5qmqzhfe85AKJ8kIvYj4 ZJfEQl38c.Pi7OyMFgeN12sOMH7UktTyC_aVvpsLWg3UyBrMMmXCWxqUOviEd2wOfSi2Y8G3rZ25 VXP3JkrCxw0w4Y6oK8PCu1WF3AarxyXEVsJVAHjdDNWvoNhQu97lm6LRo8YlRqdDTPwPQ3HlYJVz RXsv6n5XV..vCH8tnFGuqXW6tYifKZiPI3mToqE_FXvI4pkRlAYwhoNMOSfmBScbH.fj_9Djz.7G bJ3Zg11AxctUt4oIGr6vGWqA69xxco5WhSDC2B_Ki3 X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Tue, 12 Apr 2022 17:48:59 +0000 Original-Received: by hermes--canary-production-ir2-7d675798cc-zrsbx (VZM Hermes SMTP Server) with ESMTPA ID bedf5b828b1c2b5c8ec06def3560410a; Tue, 12 Apr 2022 17:48:53 +0000 (UTC) Content-Disposition: inline In-Reply-To: X-Mailer: WebService/1.1.20001 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Received-SPF: pass client-ip=74.6.128.83; envelope-from=spacibba@aol.com; helo=sonic312-21.consmr.mail.bf2.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action 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:288326 Archived-At: On Tue, Apr 12, 2022 at 01:21:53PM -0400, Alfred M. Szmidt wrote: > > >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 > Did you tried the format=1 option? >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. > See above > 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. > Agree, but any error in Exuberant Ctags has been fixed in Universal version and can be reported there to be fixed immediately. > 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... > Agree, but now their wheel is better. If they had the motivation, man power and patience to implement something more complete and compatible, in a shorter time and share it with the community for 10 years, the fact that many users prefer it and the backward compatibility they have with the original version... plus a lack of man power we have... it is pointless to duplicate the effort. Emacs developers should join effort in other direction (treesitter, lsp, project features and so on; that's my personal opinion of course.)