Re: Make all tree-sitter modes optional

[Eli Zaretskii]

> Date: Tue, 14 Feb 2023 19:08:42 +0000
> Cc: Juri Linkov <juri@linkov.net>, casouri@gmail.com,
>   monnier@iro.umontreal.ca, larsi@gnus.org, theo@thornhill.no,
>   jostein@secure.kjonigsen.net, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> Hello, Eli.
> 
> I missed this thread back in January, due to being away from Emacs
> development for a time, and I think the current state of this feature is
> so far away from ideal as to make some design and implementation
> advisable.

It's too bad you are raising this up only now, because it's too late
for any significant changes, even if I were to agree with what you
propose.

Some things you miss cannot be brought back, sorry.  You have to be
around and participate in the relevant discussions, let alone be part
of implementing the features, to have your opinions taken into
considerations when it matters.

> No, it is not adequate.  It is horrible.

Not a very kind remark, to say the least.

> How about commands c-make-ts-default-mode and c-make-ts-undefault-mode

I'm okay with adding the latter, if it turns out easy enough and safe
enough (of which I'm not sure at all), and if such a command will be
implemented for all the *-ts-modes which have non-ts siblings, but I
see no reason for the former, since there are several simple ways to
cause the same effect, and they are all documented in NEWS.

Please note, however, that a pretest is hopefully very close, and so
there isn't much time for adding such commands.  I would say that for
that reason your proposal is not practical.

> The first of these would push the new entries onto auto-mode-alist
> and the second would remove them again.

I think you have a very simplistic idea of what loading a *-ts-mode
does, but if you can come up with a simple and safe implementation, I
won't object adding such a command -- it cannot do any harm by just
being there, and if it turns to be not what users want, we can always
advise them not to use it.

> Or we could have a customisable option, c-default-c-mode which users
> could set when they are ready.

That was considered, and was found to be either too complicated in
practice or, if implemented simply, not to work well enough.  So let's
not go there.

> Either of these would allow the user to try out the new modes freely
> without being coerced against their will to use the new -ts- modes.

"Try out" is not what I had in mind for users who'd like to use these
modes.

> > The ones you proposed until now are significantly more complex, and it
> > is not reasonable to ask users to go to such lengths to try a new mode.
> 
> Any reasonable solution is going to be more complicated than the current
> code.

Then they aren't "reasonable" at this time.  Maybe later, maybe on
master.  As I said several times, we have no good idea yet how users
will react to what we have.  Maybe, after we hear from them, we decide
to implement such switches, who knows.

> I don't think it reasonable silently to force users into setting the
> new modes as defaults.

That is so far from what we have that I suspect you haven't read the
code closely enough.  NEWS explains the situation.