[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.
- Re: Unifying "foo-mode"s and "foo-ts-mode"s, (continued)
- Re: Unifying "foo-mode"s and "foo-ts-mode"s, Eli Zaretskii, 2022/12/30
- Re: Unifying "foo-mode"s and "foo-ts-mode"s, Philip Kaludercic, 2022/12/30
- Re: Unifying "foo-mode"s and "foo-ts-mode"s, Eli Zaretskii, 2022/12/30
- Re: Unifying "foo-mode"s and "foo-ts-mode"s, Philip Kaludercic, 2022/12/30
- Re: Unifying "foo-mode"s and "foo-ts-mode"s, Eli Zaretskii, 2022/12/30
- Re: Unifying "foo-mode"s and "foo-ts-mode"s, Philip Kaludercic, 2022/12/30
- Re: Unifying "foo-mode"s and "foo-ts-mode"s, Eli Zaretskii, 2022/12/31
- Re: Unifying "foo-mode"s and "foo-ts-mode"s,
Eli Zaretskii <=
- Re: Unifying "foo-mode"s and "foo-ts-mode"s, Philip Kaludercic, 2022/12/30
- Re: Unifying "foo-mode"s and "foo-ts-mode"s, Eli Zaretskii, 2022/12/30
- Re: Unifying "foo-mode"s and "foo-ts-mode"s, Philip Kaludercic, 2022/12/30
- Re: Unifying "foo-mode"s and "foo-ts-mode"s, Stefan Monnier, 2022/12/30
- Re: Unifying "foo-mode"s and "foo-ts-mode"s, Eli Zaretskii, 2022/12/30
- Re: Unifying "foo-mode"s and "foo-ts-mode"s, Richard Stallman, 2022/12/31
- Re: Unifying "foo-mode"s and "foo-ts-mode"s, Gregory Heytings, 2022/12/30