Re: Make all tree-sitter modes optional

[Juri Linkov <juri@linkov.net>]

>> This came out of the discussion in bug#60559 and other related discussions
>
> I addressed that in the discussion on emacs-devel, see
>   https://lists.gnu.org/archive/html/emacs-devel/2023-01/msg00278.html
> (I suggest to discuss this there, not here.)

Ok, moving to emacs-devel from bug#60176.

>> >> >> >> (defcustom treesit-enable-modes nil
>> >> >> >>   :type '(repeat
>> >> >> >>           (choice (function-item c-ts-mode)
>> >> >> >>                   (function-item c++-ts-mode)
>> >> >> >>                   (function-item c-or-c++-ts-mode)
>> >> >> >>                   ...
>> >> >> >>              ('c-ts-mode
>> >> >> >>               (when (treesit-ready-p 'c t)
>> >> >> >>                 (add-to-list 'major-mode-remap-alist '(c-mode . c-ts-mode))))
>> >> >> >
>> >> >> > And this bit is completely unacceptable, from where I stand: it
>> >> >> > basically means that the user activated a certain major mode he/she
>> >> >> > wanted to use, but the result could be that an entirely different mode
>> >> >> > was silently activated instead.  What kind of UX is that, and for a
>> >> >> > shining new feature at that??
>> >> >>
>> >> >> It could update 'auto-mode-alist' instead of 'major-mode-remap-alist'.
>> >> >> From the user's point of view this would be more manageable than
>> >> >> what you proposed on emacs-devel with some obscure logic of activating
>> >> >> ts modes when the package is loaded or when the mode is enabled first time.
>> >> >
>> >> > I don't understand the "obscure" part: the logic was exactly as above:
>> >> > test that treesit-ready-p returns non-nil for the mode's language.
>> >> >
>> >> > Other than that, my proposal does exactly what you say here: it
>> >> > updates auto-mode-alist.  So it sounds like we are in violent agreement.
>> >>
>> >> The difference is that an explicit option is more controllable by the user.
>> >> When the user needs to use some ts-mode then it's easier just to customize
>> >> the option instead of tweaking 'auto-mode-alist' when the user want to
>> >> start using that mode without first loading its package or calling it
>> >> the first time that modifies 'auto-mode-alist' as the side effect.
>> >
>> > With the changes I proposed, there's no need to tweak
>> > auto-mode-alist.  A simple load or require of the mode will install
>> > the mode in auto-mode-alist.  What can be easier and simpler?
>>
>> This doesn't address the problems mentioned above and below.
>
> Which parts "above" were not addressed?
>
> As for below:
>
>> >> Or when the user wants to remove the mode from 'auto-mode-alist' after
>> >> accidentally loading the corresponding ts package.

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.

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.
Also takes additional space even when users don't intend to use them
in the current session, thus negating the benefits of autoloading.

3. There is no simple way to disable a ts mode after loading
the corresponding ts file.