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: Make all tree-sitter modes optional Date: Thu, 16 Feb 2023 19:05:29 +0200 Message-ID: <83ilg135ie.fsf@gnu.org> References: <83o7rexe2n.fsf@gnu.org> <83h6x5xym7.fsf@gnu.org> <83h6wr6gmz.fsf@gnu.org> <868ri140sr.fsf@mail.linkov.net> <83fsc92gbz.fsf@gnu.org> <83cz6ccagy.fsf@gnu.org> <838rgzaqmj.fsf@gnu.org> <7bad77ae-a176-d49b-5115-dbadf7e6d1bc@yandex.ru> <83cz6aaeys.fsf@gnu.org> <837cwiae2c.fsf@gnu.org> <83r0uq839h.fsf@gnu.org> <83pma939c4.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36298"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dgutov@yandex.ru, acm@muc.de, juri@linkov.net, casouri@gmail.com, larsi@gnus.org, theo@thornhill.no, jostein@secure.kjonigsen.net, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Feb 16 18:06:17 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 1pShi5-0009Fx-8C for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Feb 2023 18:06:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pShhZ-0003FI-0X; Thu, 16 Feb 2023 12:05:45 -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 1pShhQ-0003C8-Of for emacs-devel@gnu.org; Thu, 16 Feb 2023 12:05:39 -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 1pShhO-0003Nf-5f; Thu, 16 Feb 2023 12:05:34 -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=DP4CKydSp8pd+hLWQrg387wPEFLanxV9s+E95G477A0=; b=fPgqs+uyauNG 6Bv6rFopVfUq4dmyArubbvgsfUiLy6nyzFXqVLE5ZLQSPBNcTysMGlzKaKej3m6RM5gDWWmfws6fh pbyPKShBE3S748os9CKUUscmnFEdmtXNSHwoGrdxx0fJ8i40+hKGlJFKD//AR8nnB4g3sHfUGQ2Ja 5rMLk1cS+/nvrekfO43D9V/jdAAjrblhjPJogt+d5fIaYtLgwEKfElRChF4fo5/Mi6yjgLGxWQgim 9bnj8f6Z43D/7TA6MPACJeYFEt7Q7RmyOJN5pJV3PHZQFTp1sqVpk0jT73hMZa/WXM6z7ZW2QCw3v jK3yFCbBX8lM3axSnwKJbQ==; 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 1pShhN-0005iw-22; Thu, 16 Feb 2023 12:05:33 -0500 In-Reply-To: (message from Stefan Monnier on Thu, 16 Feb 2023 11:45:30 -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:303429 Archived-At: > From: Stefan Monnier > Cc: dgutov@yandex.ru, acm@muc.de, juri@linkov.net, casouri@gmail.com, > larsi@gnus.org, theo@thornhill.no, jostein@secure.kjonigsen.net, > emacs-devel@gnu.org > Date: Thu, 16 Feb 2023 11:45:30 -0500 > > >> But with my patch, trying the modes is exactly the same (just `M-x > >> c-ts-mode`) and turning them on in their customization is no harder > >> (since `(c-ts-activate)` is no harder to type than `(require > >> 'c-ts-mode)` > > Sorry, I don't buy this argument. > > Care to expand a bit more. I don't agree that calling (c-ts-activate) in an init file is no harder than loading a package. For you and me, maybe, but not for users. > >> we could also make it a global minor mode so it can be > >> done via Custom if it's considered important). > > This was considered already, but had its own issues. > > Can you mention at least one? Sorry, I remember only the conclusion. You will have to look up the discussions. (And you were here when they happened.) > > We'll have to make this one exception to the rule. The situation > > itself is exceptional and probably won't happen again soon, if ever. > > I understand there's time pressure. But I think this would argue > towards making the code more conservative (e.g. not change the defaults > at all, not even after enabling `c-ts-mode`) since that's much less > likely to bring problems now and in the future. That'd make it significantly harder for users to try these modes, so I cannot agree to that. > E.g. if users do as (require 'c-ts-mode) as you suggest, they'll bump > into a regression when they move on to Emacs-30 where we will have > hopefully fixed this misfeature. If Emacs 30 will require different ways of activating these modes, we will document that in NEWS. Right now, the chances for such a change are very high anyhow, so I already took this into account. > I think if we want a quick&dirty short-term way to encourage the use of > tree-sitter by enthusiastic users, we should provide a "one stop shop" > function which redirects all applicable major modes to their tree-sitter > variant. That, too, was suggested a couple of months ago. It has a disadvantage of blindly assuming that a given user will either want all of the TS modes or none of them. It also assumes that a given user has all of the grammar libraries installed. Both assumptions are not necessarily true, and so I decided that we must allow the users to make separate and independent decisions for each such case. > The current code will bring bad surprises to some of our users when they > try Emacs-29, and it will bring further bad surprises later when we move > to a different solution. I understand and agree it could happen, but again: I see no better way. Every alternative that was proposed, including those proposed now, had its own disadvantages, and I think what we have now is the least of all evils. > The fix is trivial enough that the urgency doesn't pose any problem. The fix is not trivial at all. If it were, we would have found it already, as we are debating this for the past two or three months, and it's not like we lack people here who can come up with bright ideas.