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: Wed, 15 Feb 2023 20:33:49 +0200 Message-ID: <83pmaaaicy.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24401"; mail-complaints-to="usenet@ciao.gmane.io" Cc: juri@linkov.net, casouri@gmail.com, monnier@iro.umontreal.ca, larsi@gnus.org, theo@thornhill.no, jostein@secure.kjonigsen.net, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 15 19:34:35 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 1pSMby-00064l-Or for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Feb 2023 19:34:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pSMbf-0006hI-Vw; Wed, 15 Feb 2023 13:34:16 -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 1pSMbc-0006W2-EX for emacs-devel@gnu.org; Wed, 15 Feb 2023 13:34:12 -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 1pSMbb-0002f9-Id; Wed, 15 Feb 2023 13:34:11 -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=bDVMTiMe0qU05qQ8KXjsTOOUWbHUf80K/ZNslfK1mFU=; b=Gy5LwuMlo3/X bXQfcdFlccjyKEAWA6i7r4dR0Hx7HPArbY/dZf2+L60PUS8TsvEf2Eek+7Cy7KMt8DO9YVzrKp4mx Ff1TeKYd09cwF9qTMgGLZ9QIh+zpCm1ctMgSzwYTkzAlL21eYznQzKXB1uAUhCZ3UJmSvkDYTZV8a HqcDDvpMxe4ZHGKs5pFMq91S8krxiPbTnCwiKN767w7LuyimA+5ZDAnoIZU+WK9qVcUYOP67OFyLZ SorV83Y013Rqw9dpx0zQ4cs7R3cSwsTq5wGQV5slB3uRJNe1vWoN0157T3qt5f2sGoTA+L1FVSe57 UcFFpynPFWy1J4UJZfCuCw==; 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 1pSMbb-0005gu-1K; Wed, 15 Feb 2023 13:34:11 -0500 In-Reply-To: (message from Alan Mackenzie on Wed, 15 Feb 2023 17:57:15 +0000) 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:303321 Archived-At: > Date: Wed, 15 Feb 2023 17:57:15 +0000 > Cc: juri@linkov.net, casouri@gmail.com, monnier@iro.umontreal.ca, > larsi@gnus.org, theo@thornhill.no, jostein@secure.kjonigsen.net, > emacs-devel@gnu.org > From: Alan Mackenzie > > > So you revert auto-mode-alist to its original shape, but leave the > > buffers already under c-ts-mode in that mode? Is that what the users > > would expect, you think? > > I think so, yes. The scenario I am envisaging is the user tentatively > trying c-ts-mode on one, or a few buffers, then doing C-x C-f foo.c to > carry on with her work using C Mode. And when going back, they don't want their C/C++ buffers revert to C mode? I'd be surprised. > > Also, this won't work if the user customized auto-mode-alist in some > > way wrt some of those file-name extensions. > > OK. How about something like the following instead (untested)? > > (defun c-make-ts-undefault-mode () > "" > (interactive) > (let (c) > (while (setq c (rassq 'c-ts-mode auto-mode-alist)) > (setq auto-mode-alist (remq c auto-mode-alist))))) Shouldn't you add the elements of C mode back, in case they were removed? > > > > Then they [proposed amendments] aren't "reasonable" at this time. > > > > Maybe later, maybe on master. > > > > That will be too late, the damage will have been done. > > > What "damage"? why do you call "damage" changes made by others in > > Emacs as part of Emacs development? > > The damage I'm talking about is the disruption in users' work flow which > is likely to occur. Being perfectly blunt, c-ts-mode is not yet as > capable as CC Mode in some areas, and in any case its configuration is > wholly different (for good reasons). Converting to the use of c-ts-mode > is a project, not something which can just happen. The current code is > likely to confuse and anger users when, after trying out c-ts-mode, it > gradually dawns on them that the reason C Mode no longer works is that > their newly opened files aren't in C Mode at all. That is what has > happened to me several times. This can happen with any new feature. There's nothing we can do about this, so please just stop worrying about it. > I'm not calling others' changes damage. I'm calling the disruptive > effect on users' work flow damage. That disruption, once it's happened, > cannot ever be undone. With the implied assumption that the effect will necessarily be "disruptive" in many cases. Why assume that? > I'm doing my best to help. Actually, no, you aren't. "Help" would be to actively partake in the development of c/c++-ts-mode. You are our best expert on supporting these languages, so who better than you to do at least part of this job, if not coordinate and guide the few brave souls who are motivated enough to do that in record time. I'm extremely disappointed that you completely removed yourself from that effort. I think we could have ended up with much better ts modes if you took part in that these last weeks. Instead, you only speak up to describe the "disadvantages" of these new modes, and suggest ways to turn them off. > > Well, that's exactly why these new modes are entirely optional. > > They're not entirely optional, that's the whole point of my posts over > the last couple of days. One can opt in to using c-ts-mode, but opting > out again is unreasonably difficult. That's an unusual way of interpreting "opt out". One doesn't need to "opt out" of an optional behavior; instead, one should avoid turning it on, and that's all! > Even restarting Emacs (which to me is a drastic operation) won't opt > out if there are still buffers in c-ts-mode in the desktop. Many people restart Emacs all the time. And those who use desktop know how to overcome such problems, which aren't unique to these modes. > I don't think the current NEWS item makes this clear enough. The current NEWS already goes way beyond its purpose and scope in presenting these new modes and the related issues. And I object to using NEWS to tell users in too much detail how NOT to use our new features: that is like shooting ourselves in the foot. > > For you and me as users, having to restart Emacs, or having to use a > > separate session for such experiments, is an entirely reasonable and > > simple alternative, .... > > Having to restart Emacs is NOT at all reasonable for me, even if it may > be for you. Neither is having to use a separate session. We all use > Emacs differently, with different expectations. > > > .... one which should eliminate any need for undoing the "damage" of > > c-ts-mode. > > As I noted above, such restarting will not clear the state of c-ts-mode > being default whilst there are still c-ts-mode buffers in the desktop. > Anyhow, there is no mention of using a separate session in NEWS, and > restarting Emacs is incompletely documented (as already noted). Sounds like you run your full customized production environment in test runs of Emacs. The prudent thing to do is instead to either use "emacs -Q" or to have a special user/home directory which you use for such jobs. Then restarting and/or deleting the desktop is not an issue at all. I'm surprised I need to explain that, I though everybody who is involved in Emacs maintenance does that.