emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Make all tree-sitter modes optional


From: Stefan Monnier
Subject: Re: Make all tree-sitter modes optional
Date: Thu, 16 Feb 2023 11:45:30 -0500
User-agent: Gnus/5.13 (Gnus v5.13)

>> But with my patch, trying the modes is exactly the same (just `M-x
>> c-ts-mode`) and turning them on in their customization is no harder
>> (since `(c-ts-activate)` is no harder to type than `(require
>> 'c-ts-mode)`
> Sorry, I don't buy this argument.

Care to expand a bit more.

>> we could also make it a global minor mode so it can be
>> done via Custom if it's considered important).
> This was considered already, but had its own issues.

Can you mention at least one?

> And we have ran out of time needed to look for better solutions.  (I
> personally don't believe there are any that weren't already proposed.)

Giving at least one downside of the patch I propose compared to the
current code would help me understand your position.

> 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.

E.g. if users do as (require 'c-ts-mode) as you suggest, they'll bump
into a regression when they move on to Emacs-30 where we will have
hopefully fixed this misfeature.

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.  It's easy to write, it's non-intrusive, and future-proof (it
should be easy to preserve that function's approximate behavior in the
future, regardless of how tree-sitter's integration evolves).

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.

The fix is trivial enough that the urgency doesn't pose any problem.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]