unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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.



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