Re: Tree-sitter integration on feature/tree-sitter (severe performance issues together with linum-mode)

[Fu Yuan]

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

Yeah! I can do that. Do you have some ideas on the syntax you would use for 
font-lock? If possible I’d like treesit stuff to be similar to font-lock. For 
example I made treesit to use font-lock’s decoration level system.

Yuan