unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Jostein Kjønigsen" <jostein@secure.kjonigsen.net>
To: Yuan Fu <casouri@gmail.com>, emacs-devel <emacs-devel@gnu.org>,
	Theodor Thornhill <theo@thornhill.no>,
	Eli Zaretskii <eliz@gnu.org>
Subject: Suggesting that feature/tree-sitter be merged (was Re: Tree-sitter and major mode inheritance)
Date: Fri, 18 Nov 2022 22:54:49 +0100	[thread overview]
Message-ID: <cd4061ad-1cf7-2c5e-f312-616b8b170555@secure.kjonigsen.net> (raw)
In-Reply-To: <0249C656-21C8-49F2-B979-A1894BF80637@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4662 bytes --]

Hey everyone.

I know this has been said before, by people which by far has been 
contributing much more than me... But I still don't think it's a good 
idea to replace the implementation in existing major-modes with 
tree-sitter implementations, nor selectively activate tree-sitter in 
major-modes prone to inhetitence and derivation.

Me and Theodor faced these same issues with "our" C# and TypeScript 
major-modes, and the only "clean" way we agreed we could make this work 
was to create wholly new implementations. I can come up with many good, 
objective reasons for this, but I think Theodor has already represented 
this view fairly well.

While for the sake of brevity, I'll not diving deeply into this 
particular thing, I will say this: A new tree-sitter based major-mode 
free of compatibility concerns allowed us to create entirely new 
major-modes fixing most of our existing bugs, faster than we before 
would be able to fix a single bug. My personal view is that mixing 
existing major-modes with tree-sitter represents absolutely the worst of 
all worlds. It maintains all existing complexities, provides us with 
very few benefits, and at the same time adds complexities we didn't use 
to have. To me, that's a net negative.

Somewhat surprising to me, I see this is a somewhat controversial point 
of view and not as clear cut a matter as I would have expected it to be. 
I realize and respect that final decisions in these matter might take 
some time to mature. Time which given our current approach detracts from 
the momentum tree-sitter has been having.

At this point poor Yuan Fu here has spent quite a bit of time and effort 
getting a core tree-sitter interface into Emacs. I would really hate to 
see all that effort be for nothing, because we end up conflating a 
creating a core tree-sitter feature with how this feature should best be 
employed in subsequent major-modes.

So in the name of pragmatism, I propose a compromise of sorts.

Instead of waiting for "every" major-mode to be re-implemented into a 
tree-sitter derivative in the feature/tree-sitter branch before we 
merge... How about we just accept the current "core" tree-sitter 
implementation as good enough, and consider merging that to git master 
as is.

This will allow us to land one important mile-stone, while giving us the 
head-room to further discuss how we should best 
implement/reimplement/"upgrade" existing major-modes to take advantage 
of tree-sitter.

It will also allow third-party packages to make use of tree-sitter in 
Emacs core instead coming up with its own implementation, beginning a 
defacto standardization of this new API (which I may note already has a 
competing implementation in MELPA).

That is to say: We should land the core library, with holding it hostage 
to all its possible consumers being implemented.

How about it? Are there any good arguments for NOT merging 
feature/tree-sitter at this point? :)

--
Kind regards
*Jostein Kjønigsen*

jostein@kjonigsen.net 🍵 jostein@gmail.com
https://jostein.kjønigsen.no <https://jostein.kjønigsen.no>
On 16.11.2022 21:45, Yuan Fu wrote:
> So I’m trying to merge css-ts-mode with css-mode. Scss-mode inherits css-mode, but if user enables tree-sitter for css-mode, scss-mode will inherit all that tree-sitter setup, and lose all the native css setup. Then if a user doesn’t want to enable tree-sitter in scss-mode, too bad: scss-mode breaks.
>
> Essentially scss-mode needs to be able to control which parts of css-mode’s setup it wants to inherit—native setup or tree-sitter setup—regardless of whether css-mode enables tree-sitter or not.
>
> I wonder if we can do something like this:
>
>               css-mode
>                   |
>         +---------+-----+-----------+
>         |               |           |
> css-native-mode   css-ts-mode  scss-mode
>                                     |
>                                +----+------------+
>                                |                 |
>                          scss-native-mode   scss-ts-mode
>
> css-mode: a virtual mode, only sets up basic things that both native and tree-sitter mode needs, like comment-start.
> css-native-mode: native setup
> css-ts-mode: tree-sitter setup
>
> scss-mode: a virtual mode, inherits css-mode
> scss-native-mode: native setup
> scss-ts-mode: tree-sitter setup
>
> And user could use major-mode-remap-alist to choose which mode they want:
>
> (css-mode . css-ts-mode) for enabling tree-sitter
> (css-mode . css-native-mode) for not enabling tree-sitter
>
> This could also used for other modes, like c-mode: c-mode, c-native-mode (cc-mode), c-ts-mode.
>
> Yuan

[-- Attachment #2: Type: text/html, Size: 5607 bytes --]

  reply	other threads:[~2022-11-18 21:54 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-16 20:45 Tree-sitter and major mode inheritance Yuan Fu
2022-11-18 21:54 ` Jostein Kjønigsen [this message]
2022-11-18 22:34   ` Suggesting that feature/tree-sitter be merged (was Re: Tree-sitter and major mode inheritance) Philip Kaludercic
2022-11-18 22:58     ` Yuan Fu
2022-11-18 23:36       ` Stefan Monnier
2022-11-19  7:09       ` Philip Kaludercic
2022-11-19 14:07         ` Standardized access to a REPL (was: Suggesting that feature/tree-sitter be merged) Stefan Monnier
2022-11-19 15:03           ` Standardized access to a REPL Philip Kaludercic
2022-11-19 16:07             ` Stefan Monnier
2022-11-19 16:10               ` Philip Kaludercic
2022-11-19 16:18                 ` Eli Zaretskii
2022-11-19 22:31                   ` Stefan Monnier
2022-11-20  9:25                     ` Philip Kaludercic
2022-11-19  8:29     ` Suggesting that feature/tree-sitter be merged (was Re: Tree-sitter and major mode inheritance) Eli Zaretskii
2022-11-19 10:46       ` Philip Kaludercic
2022-11-19 11:36         ` Eli Zaretskii
2022-11-19 12:15           ` Philip Kaludercic
2022-11-19 13:05             ` Eli Zaretskii
2022-11-19 21:34         ` Dmitry Gutov
2022-11-18 22:52   ` Yuan Fu
2022-11-19  5:21     ` Theodor Thornhill
2022-11-19 18:35       ` Eli Zaretskii
2022-11-19 18:46         ` Theodor Thornhill
2022-11-19 18:51           ` Eli Zaretskii
2022-11-19 18:59             ` Theodor Thornhill
2022-11-19  7:36     ` Stefan Kangas
2022-11-19  8:09       ` Eli Zaretskii
2022-11-19 11:25         ` Stefan Kangas
2022-11-19 11:49           ` Theodor Thornhill
2022-11-19 12:03           ` Eli Zaretskii
2022-11-19  8:16   ` Eli Zaretskii
2022-11-19  9:41 ` Tree-sitter and major mode inheritance Yuan Fu
2022-11-19 10:26   ` Eli Zaretskii
2022-11-19 10:29     ` Po Lu
2022-11-19 15:19     ` Stefan Monnier
2022-11-19 17:17       ` Yuan Fu
2022-11-19 17:52         ` Eli Zaretskii
2022-11-19 21:45           ` Yuan Fu
2022-11-20  7:05             ` Eli Zaretskii
2022-11-20  0:38       ` Po Lu
2022-11-19 21:39     ` Dmitry Gutov
2022-11-19 21:49       ` Yuan Fu
2022-11-19 22:03         ` Dmitry Gutov
2022-11-19 22:36           ` Dmitry Gutov
2022-11-19 23:36             ` Yuan Fu
2022-11-19 23:42               ` Dmitry Gutov
2022-11-20  7:28                 ` Eli Zaretskii
2022-11-20 13:22                   ` Dmitry Gutov
2022-11-20 14:49                     ` Eli Zaretskii
2022-11-20 15:24                       ` Dmitry Gutov
2022-11-20  7:11           ` Eli Zaretskii
2022-11-20  9:19             ` Yuan Fu
2022-11-20 10:02               ` Eli Zaretskii
2022-11-20 22:57                 ` Yuan Fu
2022-11-20  7:05         ` Eli Zaretskii
2022-11-20 17:12           ` Dmitry Gutov
2022-11-20 17:34             ` Eli Zaretskii
2022-11-20  6:51       ` Eli Zaretskii
2022-11-20 12:45         ` Dmitry Gutov
2022-11-20 14:42           ` Eli Zaretskii

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=cd4061ad-1cf7-2c5e-f312-616b8b170555@secure.kjonigsen.net \
    --to=jostein@secure.kjonigsen.net \
    --cc=casouri@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=jostein@kjonigsen.net \
    --cc=theo@thornhill.no \
    /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).