[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
- Re: Tree-sitter integration on feature/tree-sitter, (continued)
- Re: Tree-sitter integration on feature/tree-sitter, Eli Zaretskii, 2022/06/17
- Re: Tree-sitter integration on feature/tree-sitter, Yuan Fu, 2022/06/17
- Re: Tree-sitter integration on feature/tree-sitter, Eli Zaretskii, 2022/06/17
- Re: Tree-sitter integration on feature/tree-sitter, Yuan Fu, 2022/06/17
- Re: Tree-sitter integration on feature/tree-sitter, Eli Zaretskii, 2022/06/18
- Re: Tree-sitter integration on feature/tree-sitter, Daniel Martín, 2022/06/20
- Re: Tree-sitter integration on feature/tree-sitter, Yuan Fu, 2022/06/20
- Re: Tree-sitter integration on feature/tree-sitter, Yoav Marco, 2022/06/18
- Re: Tree-sitter integration on feature/tree-sitter, Yuan Fu, 2022/06/17
- Re: Tree-sitter integration on feature/tree-sitter, Yoav Marco, 2022/06/18
- Re: Tree-sitter integration on feature/tree-sitter,
Yuan Fu <=
Re: Tree-sitter integration on feature/tree-sitter, Yuan Fu, 2022/06/16
Re: Tree-sitter integration on feature/tree-sitter, Yuan Fu, 2022/06/16
Re: Tree-sitter integration on feature/tree-sitter, Yoav Marco, 2022/06/28
Re: Tree-sitter integration on feature/tree-sitter, Abin Simon, 2022/06/29