Im following a convention that for struct fields that are not meant to be accesed/modified directly they should start with an underscore (_), however the ZLS changes their colour so its not as easy to spot what it is in code as it was when the fields didnt have the underscore. Is there an option to change this behaviour in the ZLS?
For me the coloring of the struct fields doesn’t change when adding an underscore as prefix, no matter if ZLS is turned on or off.
What editor are you using?
im using helix
Ok. Me too. Maybe try :lsp-stop and see if the problem persists
Or try different themes with :theme <tab>. It should live-preview.
disabled it, still the same. Also i might point out that the fields have normal colour in the struct declaration, their colour is only different when accesing the fields
Syntax highlighting in Helix is done by tree-sitter not the LSP, if I’m not mistaking. Maybe its due to the theme definition you’re using.
1 Like
yes, its the theme, kind of sad to be honest. I was using gruvbox, really liked it 
You can easily adapt it. I did the same with autumn theme. Just copy the original file to ~/.config/helix/themes/my-gruvbox.toml and edit it. Then you can load it from your config.toml inserting theme = "my-gruvbox" at the top level.
Docs here: Themes
Actually looking at the theme more i realised that the colour doesnt change for struct declaration and struct initialization, so when i looked at code that was creating an instance of struct i thought it was fixed, but its not, for for field accesing the issue persists for all themes from what i see.
In the docs I linked above is the following sub-list:
comment - Code comments
- line - Single line comments (//)
- documentation - Line documentation comments (e.g. /// in Rust)
- block - Block comments (e.g. (/* */)
- documentation - Block documentation comments (e.g. /** */ in Rust)
- unused - Unused variables and patterns, e.g. _ and _foo
From that it seems you have to change the comment.unused styling value.
But it could also be variable.other.member.private. Need to try it out…
thanks, i will try this now
no need to copy, helix lets you inherit themes and override some values.
1 Like
Yes, thats a good addition. Personally, I prefer defining the whole theme, just because it made me more clear which definitions use which value. Forgot about the inheritance. Thanks for reminding me
I tested a bit myself, out of curiosity. Unfortunately, it seems the types scope is used for chained field access when the field name starts with an underscore. If thats correct, changing the theme value won’t help too much, unless you’re okay with types and fields having the same highlighting.
But my tests were not very detailed…
yes, i did it now, changed both “comment.unused” and “variable.other.member.private” to whatever that default fields use, and nothing changed
Maybe an open task in tree-sitter scope definition for Zig