From: Eli Zaretskii <eliz@gnu.org>
To: Philip Kaludercic <philipk@posteo.net>
Cc: emacs-devel@gnu.org, casouri@gmail.com
Subject: Re: Unifying "foo-mode"s and "foo-ts-mode"s
Date: Fri, 30 Dec 2022 17:02:14 +0200 [thread overview]
Message-ID: <83zgb55409.fsf@gnu.org> (raw)
In-Reply-To: <877cy9b1k0.fsf_-_@posteo.net> (message from Philip Kaludercic on Fri, 30 Dec 2022 10:58:39 +0000)
> 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.
next prev parent reply other threads:[~2022-12-30 15:02 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-29 17:08 Need for "-ts-mode" modes Philip Kaludercic
2022-12-29 17:42 ` Eli Zaretskii
2022-12-29 18:26 ` Philip Kaludercic
2022-12-29 19:27 ` Yuan Fu
2022-12-29 19:42 ` Eli Zaretskii
2022-12-30 4:05 ` Richard Stallman
2022-12-30 8:49 ` Eli Zaretskii
2022-12-29 19:57 ` Eli Zaretskii
2022-12-29 20:23 ` Eli Zaretskii
2022-12-30 10:58 ` Unifying "foo-mode"s and "foo-ts-mode"s Philip Kaludercic
2022-12-30 12:50 ` Theodor Thornhill
2022-12-30 13:08 ` Philip Kaludercic
2022-12-30 13:19 ` Theodor Thornhill
2022-12-30 15:02 ` Philip Kaludercic
2022-12-30 15:24 ` Theodor Thornhill
2022-12-30 15:45 ` Philip Kaludercic
2022-12-30 15:42 ` Eli Zaretskii
2022-12-30 15:57 ` Philip Kaludercic
2022-12-30 16:20 ` Eli Zaretskii
2022-12-30 16:39 ` Philip Kaludercic
2022-12-30 17:05 ` Eli Zaretskii
2022-12-31 0:13 ` Philip Kaludercic
2022-12-31 6:38 ` Eli Zaretskii
2022-12-30 15:02 ` Eli Zaretskii [this message]
2022-12-30 15:20 ` Philip Kaludercic
2022-12-30 15:52 ` Eli Zaretskii
2022-12-30 16:09 ` Philip Kaludercic
2022-12-30 16:30 ` Stefan Monnier
2022-12-30 17:03 ` Eli Zaretskii
2023-01-01 3:03 ` Richard Stallman
2023-01-01 7:28 ` Eli Zaretskii
2023-01-03 4:07 ` Richard Stallman
2023-01-03 12:11 ` Eli Zaretskii
2023-01-05 3:34 ` Richard Stallman
2022-12-30 17:10 ` Gregory Heytings
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83zgb55409.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=casouri@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=philipk@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).