[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tree-sitter integration on feature/tree-sitter (severe performance i
From: |
Stefan Monnier |
Subject: |
Re: Tree-sitter integration on feature/tree-sitter (severe performance issues together with linum-mode) |
Date: |
Sat, 20 Aug 2022 10:14:43 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Yuan Fu [2022-08-19 14:58:49] wrote:
>> On Aug 18, 2022, at 11:01 PM, Jostein Kjønigsen
>> <jostein@secure.kjonigsen.net> wrote:
>>
>> On 18.08.2022 11:44, Yuan Fu wrote:
>>>
>>> Good news, the slowness can be easily resolved by compiling the query
>>> pattern in csharp-mode-font-lock-settings-1 (this is a recent addition to
>>> treesit).
>>>
>>> Yuan
>>>
>> Thanks for the reply and thanks for looking into this.
>>
>> I can confirm that by compiling the query like you suggested, and
>> replacing linum-mode with nlinum-mode, I'm not experiencing any
>> performance issues any more!
>>
>> To avoid issues like this... Should perhaps the function
>> treesit-query-capture (in treesit.c) emit a warning/message when
>> encountering non-compiled queries?
>>
>> That way writing more performant major-modes would be more
>> self-explanatory, resulting in a better, faster Emacs for everyone.
>
> Warning/message seems a bit drastic. There are valid use-cases where one
> want to use an uncompiled query. For now I have words in the docstring that
> advices using compiled queries (albeit not in all caps :-)
FWIW, I think specifying the highlighting rules with something akin to:
(defvar <foo> '<rules>)
is a mistake. It should go through some kind of macro, such as (maybe):
(defvar <foo> (tree-sitter-rules <rules>))
which can thus do any preprocessing we may want, such as pre-compiling
queries. It also helps evolve the syntax since we can more easily warn
about obsolete uses, etc...
I've had a "rewrite font-lock.el so the rules go through a macro" in my
todo list for ages.
Stefan