Re: Make all tree-sitter modes optional

[Stefan Monnier]

>> > Sorry, I don't buy this argument.
>> Care to expand a bit more.
> I don't agree that calling (c-ts-activate) in an init file is no
> harder than loading a package.  For you and me, maybe, but not for
> users.

AFAIK users do it by searching for advice (in our docs when we're
lucky, or on the web more often) and copying the code snippet they find.
The specific content of the snippet doesn't matter very much in this regard.

>> > We'll have to make this one exception to the rule.  The situation
>> > itself is exceptional and probably won't happen again soon, if ever.
>> I understand there's time pressure.  But I think this would argue
>> towards making the code more conservative (e.g. not change the defaults
>> at all, not even after enabling `c-ts-mode`) since that's much less
>> likely to bring problems now and in the future.
> That'd make it significantly harder for users to try these modes, so I
> cannot agree to that.

To temporarily try the modes, the easiest is `M-x <THEMODE>` in all cases.
To try it more lastingly, "look for the snippet, copy it to `.emacs`" is
also the same in all cases.

>> I think if we want a quick&dirty short-term way to encourage the use of
>> tree-sitter by enthusiastic users, we should provide a "one stop shop"
>> function which redirects all applicable major modes to their tree-sitter
>> variant.
> That, too, was suggested a couple of months ago.  It has a
> disadvantage of blindly assuming that a given user will either want
> all of the TS modes or none of them.  It also assumes that a given
> user has all of the grammar libraries installed.  Both assumptions are
> not necessarily true, and so I decided that we must allow the users to
> make separate and independent decisions for each such case.

The point is that it's super easy to write those helper functions.
We can write one per mode, one per group of modes and an
overarching one in less time than this discussion.  And none of those
impose any surprising behavior that breaks the conventions we preach
(and on which other code relies).

IOW, what I'm proposing is a safe and simple solution.  It's probably
not the best solution in the long term either, but it obey the
Hypocratic oath which the current code doesn't, and it will to less
suffering of the users in the long run as well because we much more
easily keep supporting it in the future.

>> The current code will bring bad surprises to some of our users when they
>> try Emacs-29, and it will bring further bad surprises later when we move
>> to a different solution.
> I understand and agree it could happen,

It's not "could" it's "will".

> but again: I see no better way.  Every alternative that was proposed,
> including those proposed now, had its own disadvantages, and I think
> what we have now is the least of all evils.

The current solution has some evil because it breaks the "no effect on
load" convention (that's the reason I keep opposing it).
I don't see what's evil about the solution I advocate.
So I don't see how the current solution is "the least of all evils".
I'm not claiming my solution is better overall, but I do think it is
"the least of all evils".

>> The fix is trivial enough that the urgency doesn't pose any problem.
> The fix is not trivial at all.

What's not trivial about my solution?

> If it were, we would have found it already,

We have :-)

> as we are debating this for the past two or three months, and
> it's not like we lack people here who can come up with bright ideas.

That debate was focused a lot more on whether modes should be merged or
not and how things like that.  This here debate is strictly about
changing Emacs configuration when we load a file.


        Stefan