Re: Suggesting that feature/tree-sitter be merged (was Re: Tree-sitter and major mode inheritance)

[Philip Kaludercic <philipk@posteo.net>]

Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:

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

I think this sounds like a good idea -- as someone who has mostly just
been following the discussions.  The core bindings and major modes that
are based on these are separate issues, with a clear dependency linked
them.

As an aside: This might also be a good opportunity to clean up some of
the current major mode implementations and make them more consistent.
The issue with custom options to enable tree-sitter for every major mode
has revealed an inherent duplication of features.  There are other
inconsistencies, especially regarding bindings for equivalent operations
(e.g. in interpreted language with a repl, how to load function into the
current session: Lisp, Prolog, Python all differ in minor details).

I can imagine a more specialised `define-generic-mode' could be of use
here, along with more "abstract" major modes for various types of
programming languages (using `prog-mode' as a base to add
`compiled-prog-mode' that has generic commands for building program,
`interpreted-prog-mode' that has generic commands for REPL
communication, ...), where the tree-sitter configuration would be one of
the attributes these modes would specify.

[...]

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

The current branch has major modes, should these be deleted before
merging?