Re: Turning on/off tree-sitter modes

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>>> Recently Philip rightly noticed that 'major-mode-remap-alist'
>>>> would be sufficient.  And indeed, such a command could be implemented
>>>> just as
>>>>
>>>>    (defun treesit-add-enabled-mode (non-ts-mode ts-mode)
>>>>      (setopt major-mode-remap-alist
>>>>              (cons (cons non-ts-mode ts-mode)
>>>>                    major-mode-remap-alist)))
>>> But is it okay to have a command modify a user option?

Yes, it's very much appropriate.

>>> Do we have examples of this anywhere else?

This happens for example in the Custom UI. 🙂
It also happens in `package--save-selected-packages`.
And if you search for `customize-mark-as-set` you'll find other
examples, most notably all global minor modes.

It usually requires checking `called-interactively` to distinguish the
case where it's "modified outside customize", which really is about
making sure that the same change won't happen behind Custom's back next
time we start Emacs (thus interfering with Custom's way to
save&restore the settings).

> Not 100% sure though - because that plan would delete the vast majority of
> the uses of the latter from the core (except for TeX's mappings, it seems).

That sounds good to me.

All the modifications of `major-mode-remap-defaults` that happen
when we *load* a package should be removed as soon as possible.

We could keep such modifications a bit longer by moving them to the
major mode's initialization function, which should be much less
problematic, but fundamentally they should also go the way of the dodo.

The only cases where setting `major-mode-remap-defaults` makes sense,
IMO, is for cases like TeX where we have a major mode that's builtin as
well as one that's not, so the var can be set according to whether the
user installed the external package or not.


        Stefan