Re: Turning on/off tree-sitter modes

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  johan.myreen@gmail.com,  
> emacs-devel@gnu.org
> Date: Sun, 24 Nov 2024 09:29:30 +0200
> 
> > - Where does the second argument come from? Do we read the first argument
> >  from the user as well?
> 
> The answer depends on the purpose of the 'treesit-add-enabled-mode'
> command that I still don't understand.  Is it supposed to be used
> in user configs as
> 
>   (treesit-add-enabled-mode 'ruby-mode 'ruby-ts-mode)
> 
> to be another way to do the same as
> 
>   (add-to-list 'major-mode-remap-alist '(ruby-mode . ruby-ts-mode))
> 
> Or maybe we want to simplify this setting.  Then we need
> not a command, but a new option 'treesit-enable-modes':
> 
>   (add-to-list 'treesit-enable-modes 'ruby-ts-mode)

When you suggest such ways of implementing user preferences, please
always consider two factors: (a) the complexity from the users' POV,
and (b) the way to undo the preference.

Using alists or lists for customization requires that users understand
the basics of lists in Emacs, and have good command of the relevant
primitives.  As the experience of default-frame-alist suggests, that
is not a trivial thing to master (IMO, default-frame-alist survives
only because most users don't customize it directly, but via
higher-level APIs like set-frame-font etc.).

Undoing the preferences is also not easy when lists/alists are used,
because there could be more than one element in the list, and it's
easy to forget to remove all of them.

> > If we want to have an option like treesit-enable-modes (allowing the user
> > to turn on all built-in ts modes), it doesn't seem like we could do that
> > without maintaining this database in some form. Only for built-in modes,
> > though.
> 
> Actually, there is already such a database in files.el:
> the default value of 'auto-mode-alist' is the database
> of file associations.

What we have in files.el is incomplete.  Some modes modify
auto-mode-alist and some have autoload cookies which do that.

> So for ts-modes that don't have a corresponding non-ts mode in core
> we need to add their file associations to 'auto-mode-alist'.
> However, not directly, but via a non-ts mode.  So, for example,
> 'auto-mode-alist' should contain '("\\.go\\'" . go-mode)',
> then 'major-mode-remap-defaults' should contain a mapping
> from 'go-mode' to 'go-ts-mode'.

This is something we need to agree to first.  Keep in mind that for
Alan Mackenzie this was the proverbial straw that broke the camel's
back, so maybe there are others who think that way.

> This will help to remove the requirement to load a ts-mode file
> to change file associations, that currently causes problems
> such as:

Removing the effect of loading the package should be the main outcome
of whatever we decide to do here, yes.

> > 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).
> 
> Agreed, 'major-mode-remap-defaults' could be removed when loading a ts-mode 
> file
> will not modify file associations anymore.

I don't think we can or should remove it, because it's useful for the
cases like the TeX/LaTeX mode (for which we set it up now by default).
I do agree that modes should probably not modify
major-mode-remap-defaults, but I'm not so sure about the commands we
are discussing here -- I see no problem for them to modify that alist,
since that will leave the last word to the users, via
major-mode-remap-alist.