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

[Yuan Fu]

> On Nov 18, 2022, at 2:34 PM, Philip Kaludercic <philipk@posteo.net> wrote:
> 
> 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’ve though of this too, other things are indent level, and documentation. I 
wrote ghelp[1] to get a uniform interface for getting documentation in 
different major modes (because I don’t have the heart to understand and modify 
help.el). A builtin, unified documentation system would be nice, like eldoc. 
But eldoc is for at-point short and quick signature/doc more than for 
full-fledged documentation like help.el.


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

Sounds nice. Though what do you mean by “one of the attributes”?

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

I think they can stay, we’ll work on them and improve them before branch is cut.

Yuan