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: Unifying "foo-mode"s and "foo-ts-mode"s Date: Tue, 03 Jan 2023 14:11:27 +0200 Message-ID: <83cz7v24y8.fsf@gnu.org> References: <877cyagmti.fsf@posteo.net> <831qoi85u7.fsf@gnu.org> <87mt76f4n4.fsf@posteo.net> <83sfgy6l0n.fsf@gnu.org> <877cy9b1k0.fsf_-_@posteo.net> <83zgb55409.fsf@gnu.org> <87fscw9av0.fsf@posteo.net> <83sfgw6g8m.fsf@gnu.org> <87v8ls7u0j.fsf@posteo.net> <83358u4st4.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34122"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 03 13:12:23 2023 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 1pCg9W-0008gr-QW for ged-emacs-devel@m.gmane-mx.org; Tue, 03 Jan 2023 13:12:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pCg8r-0001Ie-7i; Tue, 03 Jan 2023 07:11:41 -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 1pCg8f-0001DU-MN for emacs-devel@gnu.org; Tue, 03 Jan 2023 07:11:31 -0500 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 1pCg8f-00088N-Da; Tue, 03 Jan 2023 07:11:29 -0500 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=wo6iYyTbrp3HTkt/gloYaBDcRqe+Mn+BDhhalQ+mAvI=; b=fTrFYHK4pEeQ ALgXtnVW5QYlzauRcdAUN7JP0yr6Rb8pJpjVBQpuiemksZxOcKYhOAFmBvNxSv7XlmLl4ZV+N1180 5SzgnMqRrBWqoqEfST2akksxuS10Ikhs7RqbXL8LNfaflTJumEBj6ZstzPMfgkEbRZqSUNPGn7eRj 8Fp9hBy+JGn78P1R7rcR9Az19lrJjLCLDKt+6qUdLFsq4CkGpKHUzkpN+RvRQImMdpe0dVyl/zJ0F sM5xJAuIPAKrRXVWADY2CDoWgfhC9td1P0ta0gPCvdilBGw0cbGtD8dAYAjNW5UjC0ETh5nkKoIfk +XXH2OUYbtCYOc/JTSf/Xg==; Original-Received: from [87.69.77.57] (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 1pCg8W-0004wO-N6; Tue, 03 Jan 2023 07:11:21 -0500 In-Reply-To: (message from Richard Stallman on Mon, 02 Jan 2023 23:07:49 -0500) 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:302211 Archived-At: > From: Richard Stallman > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Mon, 02 Jan 2023 23:07:49 -0500 > > > And the features based on tree-sitter are not limited to > > fontifications, they also support indentation, navigation by defun and > > other language-dependent program components, and Imenu indices of > > functions, structures, etc. Each one of these needs to change quite a > > few functions and variables of the particular major mode to switch > > between tree-sitter and the "traditional" ways, and we also needed to > > introduce a lot of new data structures that are not needed for the > > "traditional" modes. > > I know. I don't think that precludes having tree-sitter be a minor > mode. The major mode command could set some variables that are used > only when tree-sitter is off, and other variables that are used only > when tree-sitter is on. In principle, yes. We just haven't yet found a way of doing this everywhere in a way that is both convenient and safe enough to release without a prolonged testing and fixing period. > > I considered that to be "a bridge too far", and > > instead decided to go with a safer, simpler alternative that we have > > now. > > It sounds like you consider the current design as a _temporary_ > expedient. If that's what it is, maybe writing this first was a good > idea. > > I'm talking about how the code should work after there is time to take > stock and clean it up. IMO, we currently lack not only time, but also (and more importantly) the necessary experience and user feedback to decide how to do it correctly. We need to collect that experience before we decide on the best arrangement. Of course, if the minor-mode idea turns out to be workable, we will seriously consider it; it's not like we rejected it for good.