Date: Sun, 5 Feb 2023 01:44:40 +0200
Cc: 61205@debbugs.gnu.org, casouri@gmail.com, theo@thornhill.no, dev@rjt.dev
From: Dmitry Gutov <dgutov@yandex.ru>
On 04/02/2023 08:53, Eli Zaretskii wrote:
Date: Sat, 4 Feb 2023 05:36:15 +0200
From: Dmitry Gutov<dgutov@yandex.ru>
Cc:61205@debbugs.gnu.org,casouri@gmail.com,theo@thornhill.no,dev@rjt.dev
Here's the updated patch in the meantime.
Thanks, but please also update the doc string of
treesit-font-lock-level.
Done.
Thanks, LGTM.
Not sure what to do with 'type' highlighting in rust-ts-mode yet.
What is the problem with that?
The nodes structure of a 'use' instruction has a lot of nesting, and at
least a couple of variations, which would lead to a combinatoric
increase in the number of queries.
If this proves to be a problem in practice, maybe we'll need some
customization specific to Rust.
Taking another look at the declarations, though, I wasn't sure I could
understand the specific logic for choosing between font-lock-type-face
and font-lock-constant-face.
It seemed heavily inspired by
https://github.com/tree-sitter/tree-sitter-rust/blob/master/queries/highlights.scm,
though. So what I did is reverted to those rules (in that area): the
path segments that start with an uppercase char get highlighted with
font-lock-type-face. The rest don't get highlighted at all. That's how
Rust code looks at Github, so a fair number of developers must be okay
with it.
And this solves the potential combinatoric explosion?