Re: Turning on/off tree-sitter modes

[Juri Linkov <juri@linkov.net>]

>>>> +  :options '((js-mode   (function :value js-ts-mode))
>>>> +             (ruby-mode (function :value ruby-ts-mode)))
>>>
>>> This :options hunk is a nice illustration, but if it's a serious proposal
>>> I wonder which set of modes would be appropriate to have here. All or most
>>> ts modes?
>> Probably the list of all ts-modes would be too long.
>> I can count 28 ts-modes in Emacs core.
>
> Could we decide on a smaller subset?

Selected by popularity?  This would be too fuzzy.

Better would be to create a collapsable outline on the
CustomUI section with all options that can be shown
by clicking on the heading.

>>> Note we still won't be able to cover all tree-sitter modes this way because
>>> a large part of them doesn't have any corresponding "traditional" modes and
>>> so no existing auto-mode-alist entries.
>> Such ts-modes can be associated with a non-ts placeholder
>> like this wishlist item in lisp/progmodes/go-ts-mode.el:
>>      ;; FIXME: Should we instead put `go-mode' in `auto-mode-alist'
>>      ;; and then use `major-mode-remap-defaults' to map it to `go-ts-mode'?
>>      (add-to-list 'auto-mode-alist '("\\.go\\'" . go-ts-mode))
>
> I guess if we're okay with "Ignoring unknown mode" errors and prefer them
> over "Cannot activate tree-sitter" errors, which are admittedly more
> verbose.

It could be defined as autoloaded (defalias 'go-mode 'go-ts-mode),
then an ELPA package can redefine 'go-mode'.