Re: Make all tree-sitter modes optional

[Eli Zaretskii]

> 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 <acm@muc.de>
> 
> > 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
> +<mode>-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.

> +(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?

Also, this won't work if the user customized auto-mode-alist in some
way wrt some of those file-name extensions.

> > 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?

> 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 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.

> > 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, one which should eliminate any need for undoing
the "damage" of c-ts-mode.