GNU bug report logs - #61302
29.0.60; rust-ts-mode does not show function-invocation on field-properties

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Randy Taylor <dev <at> rjt.dev>, jostein <at> kjonigsen.net
Cc: eliz <at> gnu.org, 61302 <at> debbugs.gnu.org
Subject: bug#61302: 29.0.60; rust-ts-mode does not show function-invocation on field-properties
Date: Mon, 13 Feb 2023 21:57:49 +0200

On 13/02/2023 16:39, Randy Taylor wrote:

>>
>>From what I can tell, neither of them is perfect yet, but they both get some things right:
>>
>>    rust-ts-mode: function invocations :)
>>    rust-ts-mode handles constants better (also escape-sequences, but not seen in this sample)
>>    rust-mode: consistently fontify annotations (notice they are missing in rust-ts-mode, line 12 and 14). Also rust-mode use font-lock-preprocessor-face, which I think as a more appropriate face for this kind of syntax, than font-lock-constant-face (used in rust-ts-mode).
>>    rust-mode: is able to handle nested macro-invocations. See line 42 and 44 above. From what I can tell, this seems to be due to a short-coming in the tree-sitter grammar for rust, and we may be able to fix it upstream, instead of monkey-patch things based on regexp's in rust-ts-mode
>>
>>As for things which are less great in rust-ts-mode:
>>
>>    some code does not seem to get fontified at all (types, keywords, etc). Line 14-17.
> 
> Did you look at that with treesit-explore-mode?
> It's inside a macro invocation which mostly consists of token_trees.
> Not much helpful stuff for us to go on to highlight.

Depending on the progress in improving the grammar, we could choose to 
add some ad-hoc Lisp based fontification to macro calls (using something 
similar to what rust-mode already does, I guess).

There's no hurry for that, though. Certainly not before Emacs 29 is out.

>>    it seems to fontify all variables using font-lock-variable-name-face all over, regardless of it is a declaration or not. I realize this is not 100% consistent throughout the Emacs-verse, but I know other -ts-modes have aimed for declaration only, and so does rust-mode from MELPA too (although with some consistency-issues) which this would be replacing.
> 
> Because that's what the variable feature is supposed to do, same as the 
> function feature.
> Perhaps rust-ts-mode's definition feature can be augmented to support 
> that

That should already work. Either try treesit-font-lock-level=3, or use 
level 4 but follow it with disabling the 'variable' feature, and you'll 
see variable bindings highlighted. In function parameters and 
let/for/match expressions.

> (and also note it's missing an assignment feature that some other 
> modes have).

I didn't bother with assignments for now (in the absence of feature 
requests), but they should be even easier to add.

Overall, I would recommend to drop the 'variable' feature as it is now 
(sorry for repeating myself), because if we reach the state where 
*everything but* variable references is already highlighted with some 
face, the variable references will stand out automatically (only they 
will be rendered with 'default' face). Adding 
font-lock-variable-name-face drops the distinction between a definition 
and a reference.

But I don't want to force this subject: if you like it enough, no 
problem. The users can disable it manually as well.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.