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

[Philip Kaludercic <philipk@posteo.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: emacs-devel@gnu.org, Yuan Fu <casouri@gmail.com>
>> Date: Fri, 30 Dec 2022 10:58:39 +0000
>> 
>> I have attached a sketch of my proposal with support for Python.
>> Instead of a separate python-ts-mode, we regulate tree-sitter support
>> using a user option `treesit-enabled-modes'.  It can either be a list
>> 
>> --8<---------------cut here---------------start------------->8---
>>   (setq treesit-enabled-modes '(python-mode c-mode))
>> --8<---------------cut here---------------end--------------->8---
>> 
>> or generally enable tree-sitter
>> 
>> --8<---------------cut here---------------start------------->8---
>>   (setq treesit-enabled-modes t)
>> --8<---------------cut here---------------end--------------->8---
>
> 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.

>> 
>> All a major modes has to do is pass a parser configuration
>> 
>> --8<---------------cut here---------------start------------->8---
>>   (define-derived-mode python-mode prog-mode "Python"
>>     "Major mode for editing Python files.
>> 
>>   \\{python-mode-map}"
>>     :syntax-table python-mode-syntax-table
>>     :parser-conf python-mode--treesit-conf
>>    ...
>> --8<---------------cut here---------------end--------------->8---
>> 
>> that expands to
>> 
>> --8<---------------cut here---------------start------------->8---
>>   (when-let
>>       ((conf python-mode--treesit-conf)
>>        ((cond
>>          ((listp treesit-enabled-modes)
>>           (memq 'python-mode treesit-enabled-modes))
>>          ((eq treesit-enabled-modes t))))
>>        ((treesit-ready-p
>>          (nth 0 conf)))
>>        (parser
>>         (treesit-parser-create
>>          (nth 0 conf))))
>>     (setq-local treesit-font-lock-feature-list
>>                 (nth 1 conf)
>>                 treesit-font-lock-settings
>>                 (nth 2 conf)
>>                 treesit-defun-name-function
>>                 (nth 3 conf)
>>                 treesit-defun-type-regexp
>>                 (nth 4 conf)
>>                 imenu-create-index-function
>>                 (nth 5 conf))
>>     (treesit-major-mode-setup))
>> --8<---------------cut here---------------end--------------->8---
>> 
>> at *the end* of the major mode definition.  Note that if no parser
>> configuration was parsed, the entire expression is byte-compiled away,
>> so there is no run-time overhead for other modes.
>
> 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.

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.

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