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: Tue, 14 Feb 2023 19:08:42 +0000 Message-ID: References: <84973.1672843723@hassadar.pretzelnet.org> <83wn62xi3k.fsf@gnu.org> <83o7rexe2n.fsf@gnu.org> <83h6x5xym7.fsf@gnu.org> <83h6wr6gmz.fsf@gnu.org> <868ri140sr.fsf@mail.linkov.net> <83fsc92gbz.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="1180"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Juri Linkov , 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 Tue Feb 14 20:10:13 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 1pS0gu-00006d-4k for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Feb 2023 20:10:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pS0fl-0006CK-KU; Tue, 14 Feb 2023 14:09:01 -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 1pS0fj-0006BN-OX for emacs-devel@gnu.org; Tue, 14 Feb 2023 14:08:59 -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 1pS0fh-0003WH-JM for emacs-devel@gnu.org; Tue, 14 Feb 2023 14:08:59 -0500 Original-Received: (qmail 33360 invoked by uid 3782); 14 Feb 2023 20:08:43 +0100 Original-Received: from acm.muc.de (pd953a83b.dip0.t-ipconnect.de [217.83.168.59]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 14 Feb 2023 20:08:42 +0100 Original-Received: (qmail 8459 invoked by uid 1000); 14 Feb 2023 19:08:42 -0000 Content-Disposition: inline In-Reply-To: <83fsc92gbz.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:303287 Archived-At: Hello, Eli. I missed this thread back in January, due to being away from Emacs development for a time, and I think the current state of this feature is so far away from ideal as to make some design and implementation advisable. On Tue, Jan 17, 2023 at 19:58:40 +0200, Eli Zaretskii wrote: > > From: Juri Linkov > > Cc: casouri@gmail.com, monnier@iro.umontreal.ca, larsi@gnus.org, > > theo@thornhill.no, jostein@secure.kjonigsen.net, emacs-devel@gnu.org > > Date: Tue, 17 Jan 2023 19:30:16 +0200 > > It fails for many scenarios: > > 1. The user needs to use e.g. js-ts-mode. Your patch requires that > > users first visit a js file in js-mode, then they need to type > > M-x js-ts-mode RET > > then for the rest of the session they can use js-ts-mode. > > But for a new session they need to repeat the same again. > Or customize auto-mode-alist. > This is a consequence of the fact that js-ts-mode doesn't have a > separate .el file. If you have better ideas for that, I'm all ears. > > 2. For other ts modes adding something like (require 'c-ts-mode) > > to the user's init file is not a clean way to enable such modes. > Why not? > > Also takes additional space even when users don't intend to use them > > in the current session, thus negating the benefits of autoloading. > Once again, if the above is somehow too annoying, they can customize > auto-mode-alist manually. Or even use use-package (and have full > benefit of autoloading). In any case, the fact that a mode is loaded > and not used is not a problem large enough to reject this simple > arrangement. Moreover, if someone puts the require into their init > file, they probably want to use the mode quite a lot, so it will not > remain ballast for too long. > > 3. There is no simple way to disable a ts mode after loading > > the corresponding ts file. > Yes, there is: restart the session. IMO, adequate enough for > something you want to try, and then find not to like. No, it is not adequate. It is horrible. It forces the user to discard all the state in his Emacs session, and restart, which is s..l..o..w.., particularly if said user has a large desktop file. In my experiments with c-ts-mode, I switched backwards and forwards several times between C Mode and c-ts-mode. This now corrupts my Emacs session, in that C Mode is no longer the default for C files. I got caught out this evening when I opened a C file, and something failed to work on it because it opened in c-ts-mode. This seems to be undocumented in NEWS. I think lots of users are going to hate having the new -ts- modes forced upon them in this manner. Normally, when a new feature is introduced into an Emacs version, it is fully optional, and defaults to disabled. Why do the -ts- modes not conform to this well established practice? There appears to be no way, apart from editing the Lisp source files, to make C Mode the default for .c files when there are also c-ts-mode buffers in the session. This is a Bad Thing. > Bottom line: if you have better, simpler solutions, please tell. How about commands c-make-ts-default-mode and c-make-ts-undefault-mode (and analogous functions for the other ts-modes)? The first of these would push the new entries onto auto-mode-alist and the second would remove them again. Or we could have a customisable option, c-default-c-mode which users could set when they are ready. Either of these would allow the user to try out the new modes freely without being coerced against their will to use the new -ts- modes. > The ones you proposed until now are significantly more complex, and it > is not reasonable to ask users to go to such lengths to try a new mode. Any reasonable solution is going to be more complicated than the current code. I don't think it reasonable silently to force users into setting the new modes as defaults. They should be able to try out a new mode simply by doing M-x c-ts-mode, or the like, then go back to their normal way of working. > But of course, if someone wants to do it in a more complex and more > flexible way, they still can. -- Alan Mackenzie (Nuremberg, Germany).