Re: Unifying "foo-mode"s and "foo-ts-mode"s

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: emacs-devel@gnu.org,  casouri@gmail.com
>> Date: Fri, 30 Dec 2022 15:20:35 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > I think we want to let the users say, for every single mode, whether
>> > they want to use the treesit-enabled variant or not, and also to be
>> > able to go back to the non-treesit mode later in the session (e.g., if
>> > they don't like the results).  A list is not a convenient means for
>> > doing so.
>> 
>> How come?  When presented in the customise interface we could make it
>> out to be a set where users get to pick what modes they want.  And
>> updating the value works fine whenever a mode is re-applied.
>
> The need to manipulate a list when all I want is to turn on or off a
> single feature is a nuisance.

This shouldn't have been an issue.  It is simple to write a command that
toggles tree-sitter support for the major mode in the current buffer.

>> > What does this mean in user-facing behavior?  Does it mean that if
>> > tree-sitter is not available, or the Python grammar fails to load for
>> > some reason, Emacs will silently fall back to the "traditional"
>> > python-mode?  If so, I don't think this is what we want.  The failure
>> > for loading tree-sitter support should not be silent.
>> 
>> I am not sure why?  Tree-sitter is an improvement in that it allows
>> Emacs to provide better highlighting and knowledge of the syntax, but in
>> the end it isn't something you think about actively -- or even should
>> have to think about.This is all backend stuff that doesn't interest the
>> casual user.  I strongly believe that the principle of "graceful
>> degradation" is the right approach here.
>
> You assume a lot here.  First you assume that everyone will see
> tree-sitter as an improvement -- that is not a given, and moreover can
> vary from language to language.  Second, you assume that whether
> tree-sitter is used doesn't interest the user -- again, not a given.
> Especially since we currently ask users to install the grammar
> libraries.

To me the ideal would still be that tree-sitter support is provided by
the distribution, just like how package managers have started bundling
libgccjit for native compilation, instead of requiring the user enable
it themselves.

> Your strong beliefs in this matter are noted, but I don't share them,
> and think that we should collect actual user experience before we make
> such significant decisions.
>
> Btw, you were previously expressing concerns about the risk of
> committing to some strategy too early -- well, I think what you
> propose will commit us to some strategy much more than what we have
> now.

It is a bit tricky for me to argue this point now that I have agreed it
shouldn't be done now, but I don't think this is a greater commitment,
since the user interface would be reduce from a number of major modes to
a single user option (another design principle I stand behind).  The
only other commitment would be that :parser-conf would be exposed as
part of `define-derived-mode'.

>> And in the end, if the tree-sitter support is hidden behind new modes, I
>> know already that most people (who don't use starter packs) will never
>> notice their existence and won't make use of the support.  There are
>> people still using linum-mode, even though display-line-numbers-mode has
>> been around for a while.
>
> There's a world of difference between tree-sitter support and a minor
> feature such as display-line-numbers-mode.  Just look at Reddit as one
> example.

I am not sure what you are referring to here.  My point was just that
features that have to be enabled manually are usually never enabled by
non-enthusiasts (which I believe are the majority, even for Emacs).

> I'm sure tree-sitter will be very visible to users.

Maybe I am in a minority here, but I know I am not alone, in having to
double-check if tree-sitter is enabled or noticing what it even changes.
I am not quite saying it is a placebo, there are certainly tricky C++
fontification cases where the difference is obvious, but simpler
languages like JSON, CSS or to a degree even C the (visual) difference
is rather minor.

>> > These are exactly the aspects of the behavior we discussed a month
>> > ago, and what we have now is the result of those discussions.
>> 
>> Could you point me to the thread(s)?  I did not have the time to follow
>> the threads in detail a month ago.
>
> Sorry, I don't have them ready and cannot afford looking them up: too
> many things on my plate.  Perhaps someone else will do that.

No problem, I'll try to find them myself.  Thanks.