emacs-devel
[Top][All Lists]
Advanced

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

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


From: Eli Zaretskii
Subject: Re: Unifying "foo-mode"s and "foo-ts-mode"s
Date: Fri, 30 Dec 2022 17:02:14 +0200

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

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

These are exactly the aspects of the behavior we discussed a month
ago, and what we have now is the result of those discussions.



reply via email to

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