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 21:40:00 +0000 Message-ID: References: <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> <83pmaaaicy.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="29333"; 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 22:41:08 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 1pSPWW-0007SA-58 for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Feb 2023 22:41:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pSPVi-000581-7n; Wed, 15 Feb 2023 16:40:18 -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 1pSPVZ-00057i-SU for emacs-devel@gnu.org; Wed, 15 Feb 2023 16:40:13 -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 1pSPVV-0004DP-LG for emacs-devel@gnu.org; Wed, 15 Feb 2023 16:40:09 -0500 Original-Received: (qmail 89444 invoked by uid 3782); 15 Feb 2023 22:40:01 +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 22:40:01 +0100 Original-Received: (qmail 26442 invoked by uid 1000); 15 Feb 2023 21:40:00 -0000 Content-Disposition: inline In-Reply-To: <83pmaaaicy.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=unavailable 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:303355 Archived-At: Hello, Eli. On Wed, Feb 15, 2023 at 20:33:49 +0200, Eli Zaretskii wrote: > > 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. I wouldn't. If I type M-x foo-mode in a buffer, I would be surprised if something changed that without asking me. > > > 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? Possibly. But we're looking for something simple and reliable at the moment. Adding code to check for the presence of c-mode in auto-mode-alist would add some complexity, and may not really be needed. > > > > > 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 think we can do things about it, hence my patch from yesterday evening and this discussion. > > 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? Because it's unexpected to the users, something which throws them out of their rhythm, and forces them to expend time and energy getting back to where they wanted to be. Not all users, but likely enough of them to matter. [ .... ] > > > 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! Again, we differ here. You're picturing a process where a user one day makes a definitive decision to switch, and does so permanently. Maybe that's how you work, it's not how I work. I would find myself with a spare few minutes, experiment a bit with the new mode, then carry on with my work, maybe experiment a bit more. I would subconsciously expect my Emacs state would not be changed by such experimentation. But it is, in a way which is difficult to reverse. Again, I don't understand why you're content that such difficulty remain. > > 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. Probably most users start Emacs in the morning and shut it down in the evening. I certainly do. I think a user who gets into this problem is going to have to spend, perhaps, between 1 and 2 hours getting it sorted out, or on the other hand, will continue dissatisfied at having to type M-x c-mode after loading each and every C file. Why do you not see this as a bad thing? > > 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. NEWS has always introduced new features, and amongst the description is (almost) always some text telling users how to restore the old behaviour. Why do we not do that here? > > > 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 thought > everybody who is involved in Emacs maintenance does that. Everybody uses Emacs differently. Even (especially) amongst Emacs developers. -- Alan Mackenzie (Nuremberg, Germany).