Re: Turning on/off tree-sitter modes

[Dmitry Gutov <dmitry@gutov.dev>]

On 23/11/2024 18:36, Eli Zaretskii wrote:
>> Date: Sat, 23 Nov 2024 18:26:21 +0200
>> Cc: johan.myreen@gmail.com, emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>>>     . we need the ability to turn on and off selected TS-based modes,
>>>       and do it easily
>>
>> Note that we don't have such capability currently.
> 
> We have, sort-of: loading the mode "turns it on" (with known caveats
> and disadvantages).  In any case, I think we should have this, even if
> we don't have it now.  It should be part of this improvement.

No capability to turn it off, I mean. Anyway, not so hard, except for 
your question regarding having a command change user option. I don't 
know if it's a problem.

>> Both commands would be pure wrappers on top of the user option, so they
>> don't seem to require any advance considerations. Somebody can add those
>> later, or any variations on them.
> 
> We could indeed make them wrappers, but changing the user option is
> not really clean.  If nothing else, users will see that the option was
> "modified outside Custom", which could be confusing.  But if we
> conclude that this is the best way, we could avoid this unpleasant
> effect as well (AFAIR, it is based on some special property of the
> option's symbol).

The indication could be helpful too - mostly in cases when the user 
opens Customize and sees an unexpected value. But we could avoid it like 
you say, saving the change as if the Customize buffer was used. Whatever 
is decided - I don't think the implementation will be a blocker.

>> I see no reason to depart from the current approach - except I've
>> switched from major-mode-remap-defaults to major-mode-remap-alist (where
>> the former is used) because the latter corresponds to user preferences,
>> and it seems like that's the subject of our switcher.
>>
>> This could also be discussed, but seems more of an orthogonal issue.
> 
> Not really orthogonal, since I think Stefan was against changing
> auto-mode-alist, because it doesn't handle mode cookies and file-local
> variables.

Orthogonal in the sense that that choice (whether we want to change that 
thing or not) doesn't affect our design here much. If we wanted to 
switch back to using auto-mode-alist uniformly - which I wouldn't 
recommend personally - the new addition wouldn't have to change much. So 
it's not something we have to revisit right now.