From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Make all tree-sitter modes optional Date: Wed, 15 Feb 2023 17:57:15 +0000 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38794"; 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: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 15 18:58:02 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 1pSM2c-0009rV-58 for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Feb 2023 18:58:02 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pSM1y-0005iL-Q7; Wed, 15 Feb 2023 12:57:22 -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 1pSM1w-0005hx-W1 for emacs-devel@gnu.org; Wed, 15 Feb 2023 12:57:21 -0500 Original-Received: from mx3.muc.de ([193.149.48.5]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pSM1u-0000Ej-GU for emacs-devel@gnu.org; Wed, 15 Feb 2023 12:57:20 -0500 Original-Received: (qmail 54193 invoked by uid 3782); 15 Feb 2023 18:57:15 +0100 Original-Received: from acm.muc.de (pd953abf4.dip0.t-ipconnect.de [217.83.171.244]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 15 Feb 2023 18:57:15 +0100 Original-Received: (qmail 25497 invoked by uid 1000); 15 Feb 2023 17:57:15 -0000 Content-Disposition: inline In-Reply-To: <838rgzaqmj.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.5; envelope-from=acm@muc.de; helo=mx3.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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:303313 Archived-At: Hello, Eli. On Wed, Feb 15, 2023 at 17:35:16 +0200, Eli Zaretskii wrote: > > Date: Tue, 14 Feb 2023 21:02:25 +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 > > > I'm okay with adding the latter, if it turns out easy enough and safe > > > enough (of which I'm not sure at all), and if such a command will be > > > implemented for all the *-ts-modes which have non-ts siblings, but I > > > see no reason for the former, since there are several simple ways to > > > cause the same effect, and they are all documented in NEWS. > > OK, Try this (so far only on c-ts-mode.): > > diff --git a/etc/NEWS b/etc/NEWS > > index 2d15e39036a..0a745d7cde9 100644 > > --- a/etc/NEWS > > +++ b/etc/NEWS > > @@ -3239,10 +3239,13 @@ for which a "built-in" mode would be turned on. For example: > > (add-to-list 'major-mode-remap-alist '(ruby-mode . ruby-ts-mode)) > > -If you try these modes and don't like them, you can go back to the > > -"built-in" modes by restarting Emacs. But please tell us why you > > -didn't like the tree-sitter based modes, so that we could try > > -improving them. > > +Normally, the loading of one of the new modes amends 'auto-mode-alist' > > +such that future visiting of the same type of file will continue to > > +use that new mode. If this is not what you want, do M-x > > +-make-ts-undefault-mode. For a more permanent effect, put, for > > +example, the following into your initialization file: > > + > > + (eval-after-load 'c-ts-mode '(c-make-ts-undefault-mode)) > Please don't delete the text in NEWS, it is a result of many > discussions and a lot of thought. Your proposal is yet another way of > going back to the non-ts modes, so simply _adding_ that to what's > already in NEWS should be much better. OK, I'll try to combine them. > > +(defun c-make-ts-undefault-mode () > > + "Make the older C and C++ Modes the default major modes for C(++) files." > > + (interactive) > > + (setq auto-mode-alist (delete '("\\.h\\'" . c-or-c++-ts-mode) > > + auto-mode-alist)) > > + (setq auto-mode-alist > > + (delete '("\\(\\.[chi]\\|\\.lex\\|\\.y\\(acc\\)?\\|\\.x[bp]m\\)\\'" . c-ts-mode) > > + auto-mode-alist)) > > + (setq auto-mode-alist > > + (delete > > + '("\\(\\.ii\\|\\.\\(CC?\\|HH?\\)\\|\\.[ch]\\(pp\\|xx\\|\\+\\+\\)\\|\\.\\(cc\\|hh\\)\\)\\'" > > + . c++-ts-mode) > > + auto-mode-alist))) > > + > 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. > 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))))) > > > 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. 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. > > It is the first experience people have of the new modes which will > > create their long term impressions of them. > Please leave that to people. We are introducing new technology to > Emacs, and try doing that in the least intrusive way. If you don't > want to help that effort (a stance that is frankly very > disappointing), at least don't bad-mouth it. I'm doing my best to help. If you don't like me using "damage", perhaps you could suggest a more acceptable synonym expressing the disadvantage about to be suffered by some of our users. > > I remember something similar happening in Emacs 21.1, when the new > > fringes were not made optional. Lots of users complained loudly and > > bitterly. > 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. 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. I don't think the current NEWS item makes this clear enough. > > > As I said several times, we have no good idea yet how users will react > > > to what we have. Maybe, after we hear from them, we decide to > > > implement such switches, who knows. > > We are ourselves all users, too. We know how we have reacted, and it is > > reasonable to try to prevent bad experiences for users similar to > > ourselves. > 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). -- Alan Mackenzie (Nuremberg, Germany).