emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tree-sitter integration on feature/tree-sitter


From: Yuan Fu
Subject: Re: Tree-sitter integration on feature/tree-sitter
Date: Sat, 18 Jun 2022 13:11:50 -0700


> On Jun 18, 2022, at 1:15 AM, Yoav Marco <yoavm448@gmail.com> wrote:
> 
> Yuan Fu <casouri@gmail.com> writes:
>>> That reminds me -- Yuan, have you seen my PR to tree-sitter-langs, Hacky
>>> support for treesit in Emacs core [2]?
>>> 
>>> It uses tree-sitter-langs' groundwork for fetching grammars and
>>> packaging highlighting queries, but uses treesit instead of the
>>> tree-sitter dynamic module.
>>> 
>>> Enabling highlighting is just M-x treesit-langs-hl-mode in major-modes
>>> that tree-sitter-langs supports.
>>> 
>>> [2]: https://github.com/emacs-tree-sitter/tree-sitter-langs/pull/99
>> 
>> Ah yes, I’ve seen it. I think the part that automatically downloads and 
>> builds
>> language definitions is very useful. It cannot be in Emacs core because we
>> cannot distribute language definitions, but it could be a very useful ELPA or
>> MELPA package.
> 
> Yeah, I agree. tree-sitter-langs makes it very easy to use
> elisp-tree-sitter and now also the newer treesit.
> 
>> The part that automatically generate highlighting is also useful,
>> but I’m not sure how would we use it.
> 
> A little neatpick -- it doesn't really 'generate', just converts
> tree-sitter-langs' hand-crafted highlights.scm query files to be usable
> by treesit too.
> 
>> We probably don’t want to add a tree-sitterify-mode that just enables
>> tree-sitter highlight in a mode—I prefer that we change each major
>> mode to use tree-sitter features.
> 
> I agree, though since grammars aren't packaged with Emacs, major-modes
> that *are* packaged with Emacs would need to only use treesit when the
> grammars are avaliable. Or do we expect grammars to be a dependency when
> users are installing Emacs?

No, we don’t distribute language definitions, built-in major-modes should 
support both tree-sitter and non-tree-sitter.

> 
>> Also I think it makes more sense if you just fork it rather than making a PR.
> 
> Yeah, I don't really expect it to be merged.
> 
> My reason for the PR is for it to be more of a talking point about
> collaboration between treesit and tree-sitter-langs. I used
> elisp-tree-sitter before trying the feature/tree-sitter branch, and I
> really like the richness of its highlighting (which comes from the
> highlights.scm files).

Do you already have the highlighting working for treesit? If so, maybe you can 
packages it in a separate package and publish it, it would be a nice 
demonstration of treesit features.

Yuan


reply via email to

[Prev in Thread] Current Thread [Next in Thread]