Re: Make all tree-sitter modes optional

[Eli Zaretskii]

> Date: Tue, 17 Jan 2023 20:49:59 +0200
> Cc: casouri@gmail.com, monnier@iro.umontreal.ca, larsi@gnus.org,
>  theo@thornhill.no, jostein@secure.kjonigsen.net, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> >> But I see you are referring to auto-mode-alist here, modifying which
> >> will still be necessary for js-ts-mode and python-ts-mode. Which will
> >> touch a lot of users, possibly even the majority of tree-sitter
> >> enthusiasts, given that JS and Python are some of the most popular
> >> languages these days.
> >>
> >> And yet you rejected my counter-proposal claiming (if I got your
> >> position right) that modying auto-mode-alist is difficult/annoying/etc
> >> for an average user. To quote:
> >>
> >>         - Customizing auto-mode-alist is not the easiest task, it
> >>           requires good knowledge of Emacs regexps and alists.  So
> >>           asking anyone who wants to try using the tree-sitter modes to
> >>           do that is not the best idea from the POV of user-friendliness.
> >>
> >> So which is it?
> > 
> > Both.  I mention auto-mode-alist as the last alternative, for those
> > who are fine with going that way.  It isn't black-and-white.
> 
> But it's either that, or "turn them on manually", right? That would also 
> work with my proposal.

Your proposal makes it harder by making it necessary to mess with
auto-mode-alist.  I hope we can make it easier, at least in many/most
cases.  That is a non-negligible advantage from my POV.

> > That's specific to js-ts-mode (and one other, I think) because they
> > share the .el file with a non-tree-sitter mode.  If there's a
> > reasonable way to give them separate files, things would be easier.
> 
> Right. If they were in separate files, then we could write the doc with 
> suggestions to merely violate the standard recommendation of avoiding 
> 'require' in the init script.
> 
> > But this is not a documentation issue, first and foremost.
> 
> Inconsistencies in design often turn up as documentation issues later.

I didn't design js.el that way.  I just assumed there were good
reasons for that and tried to adapt as best I could.