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-regen-mode: handling extensionless files Date: Thu, 26 Sep 2024 09:22:57 +0300 Message-ID: <86ed57aq7y.fsf@gnu.org> References: <87tteaznog.fsf@zephyr.silentflame.com> <8734lrrj4e.fsf@zephyr.silentflame.com> <87o74c1ce1.fsf@zephyr.silentflame.com> <86a5fwc4te.fsf@gnu.org> <87tte3jusx.fsf@tucano.isti.cnr.it> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4394"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, dgutov@yandex.ru, spwhitton@spwhitton.name To: Francesco =?utf-8?Q?Potort=C3=AC?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 26 08:23:52 2024 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 1sthuq-00010c-AZ for ged-emacs-devel@m.gmane-mx.org; Thu, 26 Sep 2024 08:23:52 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sthu3-0002ox-I7; Thu, 26 Sep 2024 02:23:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sthu1-0002oV-Lb for emacs-devel@gnu.org; Thu, 26 Sep 2024 02:23:01 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sthu0-0004U0-LD; Thu, 26 Sep 2024 02:23:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=5F5NfrlrUCO2kRPsLH6sbjaCk/PcuExEgnCtusybzy0=; b=QkYqy2oLEN+VOAmpIHK2 SY1mgrr5Qoj85A05vtrMSQFgsnou+BeIsMWp54CAMcZ70NLGwENtCvammyKHK26dEZf+qZ+FKZn8W PQ6KMZnh4IKJlwzwkNitay603QpsarJioeNzmQpg8X7q6AfV1E86d2AmoaA7MPO7IBiqilfRaYn0M aMtaaVGPzDvKcP7oKSirVWUtCQoc/CpowlD0q062TyF2Cw+no9wPw6E6CK+7Eah6N9GgulSlXiq53 m7eThJJJ8jM3MxsYTsb5p+StEiKSV3F96lVLZIwTyJrib51rZD7KzRhG7OorTZnxDTaC+hMzjiLgY lhDTvs85wepSIA==; In-Reply-To: <87tte3jusx.fsf@tucano.isti.cnr.it> (message from Francesco =?utf-8?Q?Potort=C3=AC?= on Wed, 25 Sep 2024 23:19:10 +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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:324097 Archived-At: > From: Francesco Potortì > Date: Wed, 25 Sep 2024 23:19:10 +0200 > Cc: emacs-devel@gnu.org, > dgutov@yandex.ru, > Sean Whitton > > Eli Zaretskii > >We could, but adding an option to disable the Fortran fallback is so > >easy that I hope someone will just do it... > > How about just going with the backward-incompatible change of disabling both fallbacks entirely? In my opinion the whole fallback idea was already obsolete when I worked on it in 1993. Since no one complained about it, and the only real use case is when invoking 'etags' from a Lisp program, which can easily use a non-standard option, I don't see a compelling reason for a backward-incompatible change in behavior. In some future version, we can then flip the default and make the fallback disabled by default. > Today, I can't imagine a situation where it can be useful, that is, where you work on Fortran or C sources without an extension. My gray hair tells me that our ability to imagine such situations is severely limited or biased, and we have enough evidence of this bias to not trust our imagination in these matters anymore. > On the other hand, if you are working on thirty-years old sources, I argue you should use thirty-years old tools, rather than assuming that today's tool do the right thing on them. These arguments are usually not well taken, IME. People want new tools because they give them more functionality and performance, but they do NOT want incompatibilities in the package. IOW, everyone likes to have the cake and eat it, too.