From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: An anonymous IRC user's opinion Date: Thu, 21 Nov 2024 21:47:29 +0200 Message-ID: References: <867c9htwt7.fsf@gnu.org> <387887a4-ba19-485e-8805-d1aabe2058ff@gutov.dev> <86y11xsbil.fsf@gnu.org> <17465b85-430a-4e91-8b12-769b60181ada@gutov.dev> <86ses4sglw.fsf@gnu.org> <86fro4sddd.fsf@gnu.org> <6ac73c67-cb2d-48ef-8f1d-683c5335aba5@gutov.dev> <8634k4s2r2.fsf@gnu.org> <082b0388-b3a1-4523-9f9b-5ead4b110e11@gutov.dev> <86plmrtemx.fsf@gnu.org> <7aa4a684-3374-4d0f-8efc-c4df29337c5e@gutov.dev> <86cyirtahu.fsf@gnu.org> <556779b3-9308-4fd3-9050-bf9c49658cd1@gutov.dev> <864j43t8t9.fsf@gnu.org> <4cc676e8-cac5-4348-99b0-243baf74687e@gutov.dev> <8634jnt5e3.fsf@gnu.org> <4864104c-cb23-4356-ad89-2fea111db66c@gutov.dev> <86ttc2rrh8.fsf@gnu.org> <86cyipsp94.fsf@gnu.org> <9cd17f8b-f88c-49f6-9024-0b6d297e18ac@gutov.dev> <867c8xsmri.fsf@gnu.org> <566ac897-ea5e-4141-bcb3-306d43c9118a@gutov.dev> <865xohrvfa.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2481"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: johan.myreen@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 21 20:48:38 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 1tEDAJ-0000Tl-U3 for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Nov 2024 20:48:36 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tED9N-00042m-5Q; Thu, 21 Nov 2024 14:47:37 -0500 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 1tED9L-00042W-Oz for emacs-devel@gnu.org; Thu, 21 Nov 2024 14:47:35 -0500 Original-Received: from fhigh-a5-smtp.messagingengine.com ([103.168.172.156]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tED9J-0007bF-P9; Thu, 21 Nov 2024 14:47:35 -0500 Original-Received: from phl-compute-04.internal (phl-compute-04.phl.internal [10.202.2.44]) by mailfhigh.phl.internal (Postfix) with ESMTP id 7B75D1140186; Thu, 21 Nov 2024 14:47:32 -0500 (EST) Original-Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Thu, 21 Nov 2024 14:47:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1732218452; x=1732304852; bh=52huluJu3qU/aDkH52JYfMV2xTxOGzLExNgdvTqXLDM=; b= WyYB1DQZdSmnZuGgiMXmf8/n0eFA+57p1LKtuWA7/7m03hYRPRpCejdaDZpN4DxV FxoT4j9ymE+a6GGu7+ODmzPR9E89XIjavKwqJXykujHGIKKmGjEUzNlLZCmtlYRt sUgczXtqGeWlpVbMcgHyht3NjkmfuGxQ5c38mVXM1L0TDJHaAC8cQ2EzlEQFMzX4 3XKHwU3eV1CcE1prP0h299j96XrTfHPCgSTApQs3HXhlGMFjkrCAk2dypvN5Dt9E MEdpY0z0mHTlcDXxHmFLLoSH1ncsRISqT6I+ITtnPdx3HE0TdzQ9uw2FvW8ks2/2 7niWTd4UYnvP+iozg2DyRw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1732218452; x= 1732304852; bh=52huluJu3qU/aDkH52JYfMV2xTxOGzLExNgdvTqXLDM=; b=R /nHE2thJloPAPKr05yTz82bslBgAW2S0YVBI4pAGwa8zSeecDpW0tHXfBUpNAS55 ypg148Vt60wrZb8GgMl7lwI5tj0V3hPNAfxi0ACzqAQhcfBKkVmraAdaQQu7esX6 /z+A9oVgYMz9Yc9pjfGaxdZmsyp0AO5JPTQNzFR2d8hjL00dXtbsp7Pv4Tu3HjeR ZpNsHGnKn5LTv5ET5JKpts6+aykrOY9Yvjwt8ueIn6c3BaZjQ7TbeIS9h/50u+Mn 8PzuN/gwSN1nZyrz4TohiKPXY9vEyr9qlcPmtqiH9MW7VNd4IBnbaSRTX7xUDmui qaFQbFaUloL9NJJ/24BJA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrfeeigdduvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdej necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdrug gvvheqnecuggftrfgrthhtvghrnhepffeifedvleeukedtgfelieegudfgveekfeejveej ffetffeuueeugefhveeiuddvnecuffhomhgrihhnpehgnhhurdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhht ohhvrdguvghvpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhuthdprhgtph htthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehjohhhrghnrdhmhihrvggv nhesghhmrghilhdrtghomhdprhgtphhtthhopegvmhgrtghsqdguvghvvghlsehgnhhurd horhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 21 Nov 2024 14:47:31 -0500 (EST) Content-Language: en-US In-Reply-To: <865xohrvfa.fsf@gnu.org> Received-SPF: pass client-ip=103.168.172.156; envelope-from=dmitry@gutov.dev; helo=fhigh-a5-smtp.messagingengine.com X-Spam_score_int: -26 X-Spam_score: -2.7 X-Spam_bar: -- X-Spam_report: (-2.7 / 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_SBL_A=0.1 autolearn=ham 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:325556 Archived-At: On 21/11/2024 07:46, Eli Zaretskii wrote: >>>>>> I'm fine with that idea, but it'd seem like a change in paradigm. >>>>> >>>>> Yes, indeed. So I think it has to be an optional feature, and we >>>>> should offer more "direct" ways for expressing such preferences. >>>> >>>> Such as a user option called treesit-enable-modes? >>> >>> Something like that, yes. Because no better idea was presented. >> >> Take a look at the patch, then? > > I did. What's the next step? It would be nice to understand the minimum requirements to replace the current approach. >>>>>>>> and not a replacement for the current setup. >>>>>>> >>>>>>> What current setup? >>>>>> >>>>>> Please look at the patch in >>>>>> https://lists.gnu.org/archive/html/emacs-devel/2024-11/msg00515.html, >>>>>> the current setup is on the lines being removed, and the proposed one is >>>>>> on the lines being added. >>>>> >>>>> Then I don't understand why you say modifying auto-mode-alist is not a >>>>> replacement. That's what we did in Emacs 29, just less cleanly. >>>> >>>> I said that "helpers in the Customize interface, or a command which >>>> would prompt for mode, for file extension(s), and then customize >>>> auto-mode-alist based on that" would not be ... "a replacement for the >>>> current setup", which you seem to confirm in the latest messages. >>> >>> I do? >> >> As far as I was able to understand, yes. > > Then you should understand that I think it _is_ a replacement for the > current setup, which AFAIK we all consider as sub-optimal. Here's a quote one of your previous emails: > This is okay as an opt-in feature, but it cannot be the only way for > users to tell Emacs they prefer one or more TS-based modes. For > starters, some people might be annoyed by these suggestions, and might > prefer more proactive ways of enabling those modes. I have proposed an implementation of a "more proactive way". If it seems insufficient to you, perhaps you could describe missing scenarios that are supported with the the current approach. They might be easy enough to add (or explain how they are supported already through other means). > IOW, we do want to avoid the situation where loading a mode changes > auto-mode-alist or major-mode-remap-defaults or any other global data, > right? Sure. > If so, why wouldn't those alternatives be the replacement for > that? Sorry, I don't understand your proposed alternative. If you want to see just a different set of capabilities instead, could you enumerate them?