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: etags name collision. Date: Mon, 11 Apr 2022 21:15:14 +0300 Message-ID: <837d7v5vwt.fsf@gnu.org> References: <20220411124736.3qijvtearh6wlen7.ref@Ergus> <20220411124736.3qijvtearh6wlen7@Ergus> <83pmln69n0.fsf@gnu.org> <20220411134749.ps6g5ulpbamzm6ot@Ergus> <83k0bv679q.fsf@gnu.org> <83czhn5zbc.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5020"; mail-complaints-to="usenet@ciao.gmane.io" Cc: spacibba@aol.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 11 20:17:41 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 1ndybd-00016n-MJ for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Apr 2022 20:17:41 +0200 Original-Received: from localhost ([::1]:49758 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ndybc-0005O7-4F for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Apr 2022 14:17:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35552) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndyZd-0003Tg-8S for emacs-devel@gnu.org; Mon, 11 Apr 2022 14:15:38 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46342) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndyZa-0000al-N8; Mon, 11 Apr 2022 14:15:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=V7Xsj+Po3getAWLt0V0nzBsVGYLgIoORuU303A5OR7M=; b=gGVEvj8Cv38h XoUgsHjmL14Sr32qRT4Uld18utFKdXCcSW5rnuhhzHTZN2jL6nBG9dIAQMX9RCDQgID5eieTusyZo VnTRYBnLhYxpm7IDhgDfIRvbZm3MSJfLNkZxFxq0IZWNIFZF7myVkPq04RaKtGr+humwDc8YqOuMH mej52/7oKp55L4Gr7HkgAjlkq9xOAo3GbiPNls44D3qEvaHQoh5rv3LGNpEZsFkgk6H1F8JQR2VDK HoQllcCCeDxEbSGsG90pS4j4GjDa6enfrBHsT+Etomali6uc77kaYod39eVTnKtBW3VHmu2LCdvYv aq0kTyo8Hu6RWa8K3qjtPg==; Original-Received: from [87.69.77.57] (port=3688 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndyZJ-0001CT-Mi; Mon, 11 Apr 2022 14:15:34 -0400 In-Reply-To: (message from Stefan Monnier on Mon, 11 Apr 2022 13:41:00 -0400) 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:288237 Archived-At: > From: Stefan Monnier > Cc: spacibba@aol.com, emacs-devel@gnu.org > Date: Mon, 11 Apr 2022 13:41:00 -0400 > > > I think detecting that another kind of ctags is installed is the best > > and safest way to have the cake and eat it, too. > > Rather than "install vs not-install" the test could decide "install as > `ctags` vs install as `somethingelse`", which is closer to having our > cake and eating it too since the user can then have both installed at > the same time. No, the intent is exactly to let users have the program they want under the name "ctags". Everything else, including renaming, is left to the users themsleves, because we have no way of second-guessing their habits. And as someone else pointed out, we already support installing under a different name, if the user knows what is that name. > Still, an install-time test has the downside that it won't adapt if > `ctags` is installed after Emacs is built/installed, as is probably the > case for most users nowadays (who don't build Emacs themselves but > install from a distro or from our prebuilt tarballs). I don't think we need to make too much out of it. the problem is easily solved manually, so we just make it a tad easier in one simple use case. > BTW, regarding the state of our `ctags` compared to the other ones. > A few years back I remember someone comparing them and finding out that > we support fewer languages but that for some of those languages we > provided better results. If that's not the case any more, maybe we > should check to see if we could make `etags.el` use "Exhuberant ctags" > when available so as to benefit from the better tool. That, too, is already covered by the installation of Exhuberant and other variants.