From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Make all tree-sitter modes optional Date: Thu, 16 Feb 2023 15:07:58 -0500 Message-ID: References: <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> <83ilg135ie.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4040"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) 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: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Feb 16 21:09:01 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 1pSkYu-0000mz-Ac for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Feb 2023 21:09:00 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pSkY6-0000Qv-O2; Thu, 16 Feb 2023 15:08:10 -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 1pSkY4-0000NY-Qg for emacs-devel@gnu.org; Thu, 16 Feb 2023 15:08:08 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pSkY2-0003Ae-Eg; Thu, 16 Feb 2023 15:08:08 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A56761000C4; Thu, 16 Feb 2023 15:08:01 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C18FD10000A; Thu, 16 Feb 2023 15:07:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676578079; bh=5Wq/3tZvZifxSPF1pa7pRSO+T4mMpVeM60hMZg4ufQI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Nf6BykHf6GKJToOgdFdfHeCIG5w6FuDonr6t70ewvS5zZaNSfKh4Z5gshWUTUtWXI 1d4sCHnEhHXTPD7fSdUBPt/8tOue/+FdO/iEb0TlvVFq6GJXt6BlhAlYQRCZ1Nch+C BDD7oSJJ/TpBejn2xIS/SQnYzKk9h3npn4dXf1NyQ4CT7B9iS+gj3TLzEQL2TPzZhT 0a9NgtY21kSR9sUhK3He33UAC/lL4QCqeeitP3WMj8H3mYwmD2G4ilv/NE4WvSFO68 pFRxKUdlmVAn5lsABrJ2jihFDkhqvAo8pkJOh9kd70ISJEovV45HySR51NrqhpFBqC xxq6wExfemxSg== Original-Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7677D1231B4; Thu, 16 Feb 2023 15:07:59 -0500 (EST) In-Reply-To: <83ilg135ie.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 16 Feb 2023 19:05:29 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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:303435 Archived-At: >> > 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. AFAIK users do it by searching for advice (in our docs when we're lucky, or on the web more often) and copying the code snippet they find. The specific content of the snippet doesn't matter very much in this regard. >> > 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. To temporarily try the modes, the easiest is `M-x ` in all cases. To try it more lastingly, "look for the snippet, copy it to `.emacs`" is also the same in all cases. >> 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 point is that it's super easy to write those helper functions. We can write one per mode, one per group of modes and an overarching one in less time than this discussion. And none of those impose any surprising behavior that breaks the conventions we preach (and on which other code relies). IOW, what I'm proposing is a safe and simple solution. It's probably not the best solution in the long term either, but it obey the Hypocratic oath which the current code doesn't, and it will to less suffering of the users in the long run as well because we much more easily keep supporting it in the future. >> 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, It's not "could" it's "will". > 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 current solution has some evil because it breaks the "no effect on load" convention (that's the reason I keep opposing it). I don't see what's evil about the solution I advocate. So I don't see how the current solution is "the least of all evils". I'm not claiming my solution is better overall, but I do think it 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. What's not trivial about my solution? > If it were, we would have found it already, We have :-) > 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. That debate was focused a lot more on whether modes should be merged or not and how things like that. This here debate is strictly about changing Emacs configuration when we load a file. Stefan